[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 #32 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #30)
> (In reply to comment #27)
> > (In reply to comment #26)
> > > Although this behavior frustrated me at first, the advantage is that it
> > > makes pages load *really fast* when starting the browser.
> > 
> > What's the advantage of loading very fast if contents are outdated? You have
> > to manually load again to get the current contents, which is not only slower
> > than revalidating the resources, but also very confusing. It happens to me
> > every day, I have to manually reload all the bugzilla tabs I have opened to
> > see new comments/reviews and post my comments. Fortunately I know there are
> > new contents thanks to the bug mail.
> 
> There are several advantages:
> 1. People often have tabs open they are no longer interested about. Doing
> network activity for them is wasteful (network, battery, startup time...)
> 2. Some people may have been reading a particular article on a page and may
> be surprised to get different content than the last time their browser was
> open (because we loaded fresh content from the web).
> 3. With the current behavior, users can reload only the tabs they are
> interested in getting fresh content for.

I agree all this is probably what I expect in my mobile phone where the concept of starting/closing applications is not exactly the same than in the desktop. If you want it, I can make this behavior specific to GTK+, instead of making the exception for iOS. Then we can discuss whether Mac users want this or not, and whether to expose a setting to enable/disable it.

> Your statement 'reloading' not revalidating the content seems inaccurate to
> me. Unless the client specifically requests a reload *from origin*, the
> regular reload merely revalidates cached data.

Sure, you are right.

-- 
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/20160211/ae1574d4/attachment-0001.html>