[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 #17 from Chris Dumez <cdumez at apple.com> ---
(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.

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.

> 
> The reasoning. We use the session restore for 3 different features in
> epiphany:
> 
>  1 - To restore a previous session at startup. In this case, there won't be
> page cache nor memory cache, so we will always end up in the disk cache. We
> don't want stale data in this case, users expect the browser to show updated
> contents. Not expired  resources are of course revalidated and loaded from
> the cache in any case.
> 
>  2 - To restore recently closed tabs. In this case we want to use stale data
> from any cache. It's not a problem if the history item is marked as normal
> load, because unless there's a web process crash, the resources will be in
> the page cache or memory cache (it's a recently closed tab)
> 
>  3 - In ephy, when you open a new a link in a new tab or window, the bf list
> is inherited, so that you can go back to the page from which the link was
> clicked. In this case, as in the previous one, we always want stale data
> from any cache, but we expect the resources to be in the page or memory
> cache. 
> 
> In the very unlikely case of not having the resources in the page or memory
> cache in cases 2 and 3, we would be doing a unnecessary revalidation, for
> resources that will very likely not be expired, so we will end up loading
> from the disk cache anyway. The unnecessary revalidation in these cases
> wouldn't be a problem for us at all.
> 
> Even id this is based on the particular cases of the epiphany browser, I
> think this is the desired behavior of any of our API users. If anybody
> complains we can always add a setting to enable/disable this from the API,
> but I don't think that's going to happen. 
> 
> Hope it's clearer now.

-- 
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/20160204/7366903e/attachment.html>