4 ms·

shouldBypassBackForwardCache() // Google Docs used to bypass the back/forward cache by serving "Cache-Control: no-store" over HTTPS. // We started cachi

shouldBypassBackForwardCache() // 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/forward cache Millions of pages have this bug, because of Safari's broken navigation. Nice that the big players get the browser to fix it for them. For instance, a common issue is you click a button that becomes disabled and shows a spinner while working, before forwarding to a new page. If you click back from the new page, Safari will render the previous page exactly as it was when leaving, so in a broken loading state (instead of starting it from scratch).

m_eiman 6y ago
Why shouldn't it show it in the same state? Seems like a reasonable thing to do.
- matsemann 6y ago
  If it was a static page, then sure. But for dynamic pages or SPAs it more often than not leads to going back to a page in a broken state. Other browsers have better heuristics for when this cache is used. So Safari's behavior is unexpected, even so that the big guys are taken by surprise it seems. I don't really mind either way, the main thing is that it's inconsistent. It's not a huge deal, but it's just one of many small things making Safari annoying when developing. Especially since it cannot be tested without owning an Apple device.
  - timw4mail 6y ago
    Sounds more like an issue with the web apps to me.
    - unilynx 6y ago
      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?
      - my123 6y ago
        Modern applications for Windows (UWP) and iOS do use tombstones. The app's memory itself is completely suspended/saved to disk, and then the state is restored. The app startup code is _not_ called again.
        tinus_hn 6y ago
        It has been a while since I wrote iOS app code but I’m pretty sure iOS does not, although the libraries provide a mechanism you have to save and restore state yourself. And iOS doesn’t swap, it just kills apps when it needs memory. Anyway, how would you handle connections to remote servers?
        astrange 6y ago
        iOS does sometimes swap, but only suspended processes, so you won't notice from inside the app.
        tinus_hn 6y ago
        So how do you know? Is it documented somewhere? All I could find was one unclear mention that could also be about the automatic mechanisms built in to storyboards.
        astrange 6y ago
        Probably not. It's patented though. https://patents.google.com/patent/US9720617B2/en https://patents.google.com/patent/US9720617B2/en
  - my123 6y ago
    You can test GNOME Web (Epiphany) just fine, which does use the same engine.
  - arghwhat 6y ago
    GNOME Web is a webkit browser to name an example of non-Apple Web browsers. From my perspective this is an application bug, and relying on heuristics is a bad idea. If a change should be made, it should be to make it explicitly the web apps task to handle on its own.
  - m_eiman 6y ago
    Conceptually I'd say that clicking a link and then clicking Back should be the same as right-clicking the link and opening it in a new window, and then closing that window. But it wouldn't surprise me if "web apps" makes this hard for some reason.
    - jay_kyburz 6y ago
      In my mind the forward back buttons apply to the URL. So you are going back and forward in URL history, as if you were typing the URL in fresh each time. In the old days the back forward buttons were right there next to the URL on the toolbar. It just occurred to me that on mobile, the back button is not associated with the URL at all, so its not surprising that people don't associate it with that anymore. I think safari desktop hides the URL as well.
  - tannhaeuser 6y ago
    No, it's just one of too many things, big and small, making browser web apps annoying. The entire point of a browser was a relatively simple viewer app that renders docs ok on most devices; not an opionated renderLikeChrome mode. If the basic concept of leaving a page for linked content, then coming back can't be handled without heuristics, then clearly the web app model is broken af.
  - ksec 6y ago
    >Especially since it cannot be tested without owning an Apple device. Yes very annoying. They dont have to bring Safari on Windows, but at least WebKit on Windows would be nice for testing. In the mean time, Otter for Cross Platform Browser [1], or you could do Gnome Web with Windows WSL2. [1] https://github.com/OtterBrowser/otter-browser https://github.com/OtterBrowser/otter-browser
  - capableweb 6y ago
    > But for dynamic pages or SPAs it more often than not leads to going back to a page in a broken state. Definitely a page concern, not the browsers. This problem is also easy to fix and a solution has been known for many years by now: handle navigation via the URL always! (or, modern take: via the history API). A modal opens? The URL should change and because the URL changed to that specific path, show the modal. Now users can bookmark or go back/forward without any issues of pages being broken.
machello13 6y ago
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?
- pcr910303 6y ago
  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.
  - capableweb 6y ago
    The closest you get for how browsers should act regarding history is part of the HTML spec here: https://html.spec.whatwg.org/multipage/history.html https://html.spec.whatwg.org/multipage/history.html Of course, the exact implementation is not specified, browsers are free to either implement cached behavior, which I think Firefox does as well, or just a naive refresh.
    - tinus_hn 6y ago
      I think the closest is the pagehide event https://html.spec.whatwg.org/multipage/browsing-the-web.html#event-pagehide https://html.spec.whatwg.org/multipage/browsing-the-web.html... Which appears to be supported in Safari, just like all the other browsers.
  - gsnedders 6y ago
    There's a metabug on HTML at https://github.com/whatwg/html/issues/5880 https://github.com/whatwg/html/issues/5880 about defining how various platform-exposed features behave in the face of a bfcache (backwards/forwards cache).
GranPC 6y ago
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?
- matsemann 6y ago
  We use this to force a refresh: https://stackoverflow.com/a/13123626/923847 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)
  - GranPC 6y ago
    Great! Looks like a proper way to do what I was trying to do. Thank you! My web app is a game, so fixing everything without a refresh is unfortunately pointless for the most part, and forcing a refresh also ensures players are running the latest version if they've been away for a while.
zachrip 6y ago
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.
- matsemann 6y ago
  https://stackoverflow.com/a/13123626/923847 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.
  - zachrip 6y ago
    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.
    - matsemann 6y ago
      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).

m_eiman 6y ago

Why shouldn't it show it in the same state? Seems like a reasonable thing to do.

matsemann 6y ago
If it was a static page, then sure. But for dynamic pages or SPAs it more often than not leads to going back to a page in a broken state. Other browsers have better heuristics for when this cache is used. So Safari's behavior is unexpected, even so that the big guys are taken by surprise it seems. I don't really mind either way, the main thing is that it's inconsistent. It's not a huge deal, but it's just one of many small things making Safari annoying when developing. Especially since it cannot be tested without owning an Apple device.
- timw4mail 6y ago
  Sounds more like an issue with the web apps to me.
  - unilynx 6y ago
    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?
    - my123 6y ago
      Modern applications for Windows (UWP) and iOS do use tombstones. The app's memory itself is completely suspended/saved to disk, and then the state is restored. The app startup code is _not_ called again.
      - tinus_hn 6y ago
        It has been a while since I wrote iOS app code but I’m pretty sure iOS does not, although the libraries provide a mechanism you have to save and restore state yourself. And iOS doesn’t swap, it just kills apps when it needs memory. Anyway, how would you handle connections to remote servers?
        astrange 6y ago
        iOS does sometimes swap, but only suspended processes, so you won't notice from inside the app.
        tinus_hn 6y ago
        So how do you know? Is it documented somewhere? All I could find was one unclear mention that could also be about the automatic mechanisms built in to storyboards.
        astrange 6y ago
        Probably not. It's patented though. https://patents.google.com/patent/US9720617B2/en https://patents.google.com/patent/US9720617B2/en
- my123 6y ago
  You can test GNOME Web (Epiphany) just fine, which does use the same engine.
- arghwhat 6y ago
  GNOME Web is a webkit browser to name an example of non-Apple Web browsers. From my perspective this is an application bug, and relying on heuristics is a bad idea. If a change should be made, it should be to make it explicitly the web apps task to handle on its own.
- m_eiman 6y ago
  Conceptually I'd say that clicking a link and then clicking Back should be the same as right-clicking the link and opening it in a new window, and then closing that window. But it wouldn't surprise me if "web apps" makes this hard for some reason.
  - jay_kyburz 6y ago
    In my mind the forward back buttons apply to the URL. So you are going back and forward in URL history, as if you were typing the URL in fresh each time. In the old days the back forward buttons were right there next to the URL on the toolbar. It just occurred to me that on mobile, the back button is not associated with the URL at all, so its not surprising that people don't associate it with that anymore. I think safari desktop hides the URL as well.
- tannhaeuser 6y ago
  No, it's just one of too many things, big and small, making browser web apps annoying. The entire point of a browser was a relatively simple viewer app that renders docs ok on most devices; not an opionated renderLikeChrome mode. If the basic concept of leaving a page for linked content, then coming back can't be handled without heuristics, then clearly the web app model is broken af.
- ksec 6y ago
  >Especially since it cannot be tested without owning an Apple device. Yes very annoying. They dont have to bring Safari on Windows, but at least WebKit on Windows would be nice for testing. In the mean time, Otter for Cross Platform Browser [1], or you could do Gnome Web with Windows WSL2. [1] https://github.com/OtterBrowser/otter-browser https://github.com/OtterBrowser/otter-browser
- capableweb 6y ago
  > But for dynamic pages or SPAs it more often than not leads to going back to a page in a broken state. Definitely a page concern, not the browsers. This problem is also easy to fix and a solution has been known for many years by now: handle navigation via the URL always! (or, modern take: via the history API). A modal opens? The URL should change and because the URL changed to that specific path, show the modal. Now users can bookmark or go back/forward without any issues of pages being broken.

machello13 6y ago

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?

pcr910303 6y ago
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.
- capableweb 6y ago
  The closest you get for how browsers should act regarding history is part of the HTML spec here: https://html.spec.whatwg.org/multipage/history.html https://html.spec.whatwg.org/multipage/history.html Of course, the exact implementation is not specified, browsers are free to either implement cached behavior, which I think Firefox does as well, or just a naive refresh.
  - tinus_hn 6y ago
    I think the closest is the pagehide event https://html.spec.whatwg.org/multipage/browsing-the-web.html#event-pagehide https://html.spec.whatwg.org/multipage/browsing-the-web.html... Which appears to be supported in Safari, just like all the other browsers.
- gsnedders 6y ago
  There's a metabug on HTML at https://github.com/whatwg/html/issues/5880 https://github.com/whatwg/html/issues/5880 about defining how various platform-exposed features behave in the face of a bfcache (backwards/forwards cache).

GranPC 6y ago

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?

matsemann 6y ago
We use this to force a refresh: https://stackoverflow.com/a/13123626/923847 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)
- GranPC 6y ago
  Great! Looks like a proper way to do what I was trying to do. Thank you! My web app is a game, so fixing everything without a refresh is unfortunately pointless for the most part, and forcing a refresh also ensures players are running the latest version if they've been away for a while.

zachrip 6y ago

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.

matsemann 6y ago
https://stackoverflow.com/a/13123626/923847 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.
- zachrip 6y ago
  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.
  - matsemann 6y ago
    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).