[Webkit-unassigned] [Bug 230343] Page does not reload properly when cold starting Safari

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=230343

--- Comment #9 from Chris Dumez <cdumez at apple.com> ---
(In reply to Mads Erik Forberg from comment #8)
> (In reply to Chris Dumez from comment #7)
>  > It is intentional because this is a session restore and we believe a lot
> of
> > users will want to see the content they were seeing before exiting Safari.
> > It also requires less resources (network & cpu) to load from cache. Also, if
> > the user want to refresh the content, that's what the reload button is for.
> 
> 
> I get that, for some pages, but for a frontpage of a news site it can get
> stale pretty quickly.
> 
> 
> > 
> > I am not aware of any mechanism to avoid this although I am sure somebody
> > could write JavaScript to reload the page under the right circumstances.
> 
> 
> Tried to use `document.lastModified` to check for stale content. But that
> property is updated to the current date when opening the browser, even
> though the content is older.

That seems unexpected. I looked at our code and document.lastModified is only supposed to fall back to the current date if we couldn't find or parse the Last-Modified HTTP header on the main resource response. Are you sure this header is present and properly formatted? If so, you can file a bug about that (ideally with a repro case) and I am happy to take a look.

You could also imagine getting the content's freshness from a hidden HTML element that is part of the content served by the server and then checking it on JS side.

There are definitely ways to implement this in JS if you really want to.

> 
> 
> > Sure, no-store will also avoid this behavior because you disable caching
> > altogether.
> 
> 
> Yep. I would hope there was a header or smth. that can be used for a "best
> of both world" scenario. Where you would get fresh content from current site
> and still have BFCache when navigating in the new session.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210920/b616b4a8/attachment.htm>