[Webkit-unassigned] [Bug 153230] Network cache: old pages returned by disk cache on history navigation after session is restored

[bugzilla-daemon at webkit.org]

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

--- Comment #9 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Chris, are you open to adding an option for API users to choose the desired
> > > behavior here?
> > 
> > It's not just a matter of adding API, we need a way to figure out when you
> > are doing a history navigation of an items restored from the session or not.
> > It's obvious in the case of the first navigation after a session restore,
> > but then you could go back/forward on any webview and you don't know if the
> > item you are going to was restored from the session or not.
> 
> I personally do not understand the history navigation problem. On history
> navigation, we always returned potentially stale data. I don't think it
> matters if the history navigation happened after a session restore or not
> (or I misunderstood something).

The main difference is that for normal history navigation you are in the same session, so it's very unlikely that the page has changed, and you know you are visiting a page that you have recently loaded. In case of session restoring, the fact that we need to do a history navigation is actually an implementation detail, what the user does is just starting up the browser. The back forward list restored can be very old, so in that case when you navigate back, you expect to visit the same page, but definitely not the same contents (imagine you started your browser after several days).

> About the Restoring from cache on session restore. we could support both
> behavior with a setting if needing (basically rolling out
> http://trac.webkit.org/changeset/181815 and making it conditional based on
> the new setting). To my knowledge, Safari 9 shipped with this behavior
> (session restore from the cache). There has not been much push back so far
> so I am not planning to go back to the previous behavior at this point. If
> there is push back though, we could restore the previous behavior on desktop.

I think it's a good idea to keep the current behaviour when recovering from a web process crash, when we are still in the same session but we have lost the page and memory caches. So, maybe we could do something smarter here, and mark somehow the items when they are created by session restore, and unmark them when they are first loaded, so that the first time we always revalidate them and then we don't.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160122/ba4f9fed/attachment.html>