[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 #19 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #18)
> (In reply to comment #17)
> > (In reply to comment #14)
> > > Let me explain what I think it's the desired behavior here, at least for GTK:
> > > 
> > >  - For any BF navigation we always want stale data. If the page is in the
> > > page cache, that should always be used, if the page cache is disabled, then
> > > the memory cache, and if it's not in the memory cache, then stale data from
> > > the disk cache.
> > > 
> > >  - For a BF navigation of an item that was restored from the session as
> > > requested by the API, we always want stale data from the page cache or the
> > > memory cache, but not from the disk cache. So, it's considered a normal load
> > > only by the disk cache. This not only affects the BF navigation that happens
> > > right after restoring the session, but also to any other history item
> > > created by the session restore.
> > 
> > I don't think it is ever possible currently to have a PageCache entry for a
> > HistoryItem after a session restore. On session restore, you essentially get
> > a new HistoryItem and PageCache entries are associated to a specific
> > HistoryItem.
> 
> Aha, good point.

I remember now, the thing is that whether it was restored from the session only matters for the first time it's loaded. So, if you restore a page from the session, then you navigate, and then go back, the page is now in the page cache and you want to use it now. If we change the load type, we just need to unflag the history item after navigating to it.

> > Regarding the MemoryCache, I don't think there would be anything either,
> > considering the memory cache is per WebProcess. On session restore, you get
> > fresh tabs and normally new WebProcesses AFAIK.
> 
> Unless you have a process limit of 1, but yes I get your point.

Same here, in this case it would only happen if the page cache is disabled.

-- 
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/20160205/ed732649/attachment.html>