Wow, this is terrible. Either fix the bugs, introduce non-standard behavior for all sites, or expect these big players to fix their own problems.
WebKit Quirks
41–50 of 91 posts
Re: WebKit Quirks
#42Earlier quoted context omitted.
There is no spec to conform to to work around these cache issues. (IE was even worse in the past, shutting down the back forward cache if devtools were opened. Have fun debugging that) But imagine Windows opening an app, drawing the last known interface state and then skipping half of the app startup code. Should apps deal with that too, or would it be considered a Windows bug?
The spec. doesn’t cover this case explicitly, but the general gist of RFC 2616 is very much on the side of “don’t reload things”: > History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved. — h…
RFC 2616 is long obsolete; the section you cited is now https://tools.ietf.org/html/rfc7234#section-6 and is substantially reworked. The chunk you refer to has been removed, because it no longer reflected reality in any way. Even as originally specified, as a SHOULD, it wasn’t ever practical to implement completely because of memory requirements. Since 1999, a lot has changed, and the fact of the matter was that the original recommendation just didn’t make sense any more, worded as strongly as it was. So instead they’ve switched it round to essentially say that you may redisplay an earlier-retrieved representation (rather than that you SHOULD NOT do the opposite).
Re: WebKit Quirks
#43> domain.endsWith("hulu.com") Huh, does that mean it would also apply on "thisisnothulu.com"? Most other endsWith calls seem to do e.g. `domain.endsWith(".hulu.com")` to only match subdomains.
This is to enable Safari's legacy EME implementation. I wonder if there are any vulnerabilities waiting in those unmaintained legacy codepaths
https://github.com/WebKit/webkit/blob/master/Source/WebCore/...
I first noticed this bug a year ago last February and it's been unchanged ever since.
Re: WebKit Quirks
#44shouldBypassBackForwardCache() // Google Docs used to bypass the back/forward cache by serving "Cache-Control: no-store" over HTTPS. // We started caching such content in r250437 but the Google Docs index page unfortunately is not currently compatible // because it puts an overlay (with class "docs-homescreen-freeze-el-full") over the page when navigating away and fails // to remove it when coming back from the back/…
I've actually been dealing with this issue. Does anyone have an easy way to resolve it? It causes some pretty nasty rendering issues in our app.
Re: WebKit Quirks
#45shouldBypassBackForwardCache() // Google Docs used to bypass the back/forward cache by serving "Cache-Control: no-store" over HTTPS. // We started caching such content in r250437 but the Google Docs index page unfortunately is not currently compatible // because it puts an overlay (with class "docs-homescreen-freeze-el-full") over the page when navigating away and fails // to remove it when coming back from the back/…
What makes it broken, out of curiosity? Is there a spec anywhere that suggests that behavior is incorrect? Or is it just because it's not what Chrome does?
Yeah, I'm interested too. I might be wrong, but AFAIK there aren't any specs on how a browser should implement forward/back buttons, right?
I'm personally getting a ton of mileage on the Safari's much more stable forward/back cache, the fact that you can go back reliably gives me more comfort than other browsers where going back usually refreshes the page (although I can't really explain how this is much better). I personally feel that this bug is more of a web app bug rather than the browser.
Re: WebKit Quirks
#46Earlier quoted context omitted.
IIRC, the “checking for a solution to the problem” dialogs were added because they (Microsoft) would submit an actual bug report to the developers, and if they offered a solution, Microsoft’s servers would respond with it. I’ve never seen it work, but IIRC, they added it back in the Windows 95 days (when there was a lot less software to deal with).
They really need to get rid of this.
You can disable it using group policy https://admx.help/?Category=Windows_10_2016&Policy=Microsoft...
Re: WebKit Quirks
#47shouldBypassBackForwardCache() // Google Docs used to bypass the back/forward cache by serving "Cache-Control: no-store" over HTTPS. // We started caching such content in r250437 but the Google Docs index page unfortunately is not currently compatible // because it puts an overlay (with class "docs-homescreen-freeze-el-full") over the page when navigating away and fails // to remove it when coming back from the back/…
I've actually been dealing with this issue. Does anyone have an easy way to resolve it? It causes some pretty nasty rendering issues in our app.
https://stackoverflow.com/a/13123626/923847
Can force a refresh when the page us navigated back to. Or use that event to fix whatever state your in.
Re: WebKit Quirks
#48shouldBypassBackForwardCache() // Google Docs used to bypass the back/forward cache by serving "Cache-Control: no-store" over HTTPS. // We started caching such content in r250437 but the Google Docs index page unfortunately is not currently compatible // because it puts an overlay (with class "docs-homescreen-freeze-el-full") over the page when navigating away and fails // to remove it when coming back from the back/…
I'm actually having a similar issue with my web app currently and I'm not sure what the best way to solve it would be. I was thinking of setting a checkbox in an invisible form when the page loads initially, and force a real reload if the checkbox was previously set, but that seems like a terrible hack. Any ideas?
We use this to force a refresh: https://stackoverflow.com/a/13123626/923847
Or you can use that event to fix what's wrong on the page without a refresh if possible (remove a modal, enable the button again etc)
Re: WebKit Quirks
#49Earlier quoted context omitted.
I've actually been dealing with this issue. Does anyone have an easy way to resolve it? It causes some pretty nasty rendering issues in our app.
https://stackoverflow.com/a/13123626/923847 Can force a refresh when the page us navigated back to. Or use that event to fix whatever state your in.
Full refresh defeats the purpose of a spa unfortunately. I just tested that event and it actually doesn't appear to fire when navigating backwards, only when the page is initially shown...which contradicts the comments in that code.
Re: WebKit Quirks
#50Earlier quoted context omitted.
https://stackoverflow.com/a/13123626/923847 Can force a refresh when the page us navigated back to. Or use that event to fix whatever state your in.
Full refresh defeats the purpose of a spa unfortunately. I just tested that event and it actually doesn't appear to fire when navigating backwards, only when the page is initially shown...which contradicts the comments in that code.
Maybe you misunderstand the original issue. This is when navigating back to a "new" page, not internally in a SPA. But this issue mainly happens when navigating back to a page with dynamic behavior (typically a SPA or other interactive application).