[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 #37 from Chris Dumez <cdumez at apple.com> ---
(In reply to comment #36)
> (In reply to comment #35)
> > (In reply to comment #34)
> > > (In reply to comment #33)
> > > > Comment on attachment 270743 [details]
> > > > Try to fix mac builds
> > > > 
> > > > View in context:
> > > > https://bugs.webkit.org/attachment.cgi?id=270743&action=review
> > > > 
> > > > > Source/WebKit2/WebProcess/WebPage/WebBackForwardListProxy.cpp:52
> > > > > +    bool restoredFromSession;
> > > > 
> > > > A thought just occurred to me. Don't we need to reset this flag at some
> > > > point? Otherwise, it seems like we would *never* again use the back/forward
> > > > cache policy to these history items (unless the HistoryItems get regenerated
> > > > somehow?).
> > > 
> > > That was my first idea, but it was not easy to decide when to reset it, and
> > > I realized that it was not actually needed, because after the first time,
> > > the resource will always hit the page cache or the memory cache if the page
> > > cache is disabled, but we won't reach the disk cache again.
> > 
> > It *may* use the PageCache or the memory cache but there is definitely no
> > guarantee of this happening AFAIK. Relying on this seems wrong.
> 
> Ok, I assumed it was correct, I'll update the patch to reset the value then.
> Do you know in which case we would en up in the disk cache again?

On memory pressure, we clear both the PageCache and the memory cache for example. These are caches and they get pruned / cleared so you cannot expect something specific to be in there for sure.

-- 
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/20160215/5858750a/attachment-0001.html>