[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 #18 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(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.

> 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.

-- 
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/34cd9b11/attachment-0001.html>