[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 #10 from Mads Erik Forberg <mads at langesund.org> ---
(In reply to Chris Dumez from comment #9)
> (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.


I’ll have a look at the header, thanks! :) 
I was just hoping for a header so I could avoid javascript and refetch fre

(In reply to Chris Dumez from comment #9)
> (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.



Thanks! I’ll dig into last modified in our end. Thanks!
I was just hoping for a «header-way» of refreshing the content to avoid JavaScript so the browser doesn’t wait for the JS execution before refreshing :)

-- 
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/0b74522c/attachment.htm>