[Webkit-unassigned] [Bug 49838] Image Subresource Loads Should Not Prevent Page Cache Entry

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Dec 2 15:50:48 PST 2010


https://bugs.webkit.org/show_bug.cgi?id=49838





--- Comment #8 from Joseph Pecoraro <joepeck at webkit.org>  2010-12-02 15:50:48 PST ---
This patch raises a question about what back behavior is intended to be:

  (1) Takes you back to a stale page, closely representing what you last saw
        that page to be. Potentially broken.

  (2) Take you back to a working page, no matter if the cost is a reload.

It looks like so far, WebKit strongly favors (2).

In this patch, I sided with (1) in cases where the page was unlikely to break
in serious ways; hence the choice to allow this to happen only for image
subresource loads. Given that this is a change in behavior, is this a change
that we want to put into WebKit? Maybe it be hidden behind an ENABLE flag,
such as BACK_IGNORES_LOADERS or HISTORY_IS_LAST_SEEN. The idea here
is to improve back performance in cases where reloading the page would be
costly (slow network, small cache).

I chatted with Alexey about some ideas for this. He had a couple ideas points:

  • "I think that we shouldn't allow more brokenness than IE and Firefox"
  • https://bugs.webkit.org/show_bug.cgi?id=10199
  • it might be appropriate to add target type to ResourceLoader

Maybe there is also a more generic issue with subresources. So, instead of
just image loads, it may make sense to ignore any subresource loads triggered
by the user action. For example this test case was a user click triggers an
image load and navigation that immediately cancels the load. Probably any
load type that happened as a result of that user action can be ignored, since
it won't have a chance of succeeding.

I feel like I need to do more testing on this, to come up with some concrete
examples and numbers to see if this is really a worthwhile improvement.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list