Add quirk to disable to back/forward cache on docs.google.com. docs.google.com used to bypass the back/forward cache by serving "Cache-Control: no-store" over HTTPS. We started caching such content in r250437 but the docs.google.com content unfortunately is not currently compatible because it puts an overlay over the page and starts an animation when navigating away and fails to remove those when coming back from the back/forward cache (e.g. in 'pageshow' event handler).
<rdar://problem/59893415>
Created attachment 391990 [details] Patch
Comment on attachment 391990 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=391990&action=review > Source/WebCore/page/Quirks.cpp:634 > + if (topURL.protocolIs("https") && equalLettersIgnoringASCIICase(host, "docs.google.com")) { Hm... this wouldn't work with Google's hosted apps, would it?
(In reply to Ryosuke Niwa from comment #3) > Comment on attachment 391990 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=391990&action=review > > > Source/WebCore/page/Quirks.cpp:634 > > + if (topURL.protocolIs("https") && equalLettersIgnoringASCIICase(host, "docs.google.com")) { > > Hm... this wouldn't work with Google's hosted apps, would it? Good point. Ideally, we'd find another way to detect google docs which does not rely on the host. Will need to think about it.
(In reply to Chris Dumez from comment #4) > (In reply to Ryosuke Niwa from comment #3) > > Comment on attachment 391990 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=391990&action=review > > > > > Source/WebCore/page/Quirks.cpp:634 > > > + if (topURL.protocolIs("https") && equalLettersIgnoringASCIICase(host, "docs.google.com")) { > > > > Hm... this wouldn't work with Google's hosted apps, would it? > > Good point. Ideally, we'd find another way to detect google docs which does > not rely on the host. Will need to think about it. Do they add some kind of event listener, meta tag, etc... that makes it easy to target?
Created attachment 392034 [details] Patch
(In reply to Ryosuke Niwa from comment #5) > (In reply to Chris Dumez from comment #4) > > (In reply to Ryosuke Niwa from comment #3) > > > Comment on attachment 391990 [details] > > > Patch > > > > > > View in context: > > > https://bugs.webkit.org/attachment.cgi?id=391990&action=review > > > > > > > Source/WebCore/page/Quirks.cpp:634 > > > > + if (topURL.protocolIs("https") && equalLettersIgnoringASCIICase(host, "docs.google.com")) { > > > > > > Hm... this wouldn't work with Google's hosted apps, would it? > > > > Good point. Ideally, we'd find another way to detect google docs which does > > not rely on the host. Will need to think about it. > > Do they add some kind of event listener, meta tag, etc... that makes it easy > to target? Here is an alternative fix that works by detecting the overlay that they put on top of the page when navigating away.
Comment on attachment 392034 [details] Patch Looks good to me.
Comment on attachment 392034 [details] Patch Clearing flags on attachment: 392034 Committed r257714: <https://trac.webkit.org/changeset/257714>
All reviewed patches have been landed. Closing bug.
Is it really correct to have such a quirk specifically for Google Docs? Any other web application can be potentially broken, as they may rely on Cache-Control headers to work properly in any navigation.
(In reply to Konstantin Tokarev from comment #11) > Is it really correct to have such a quirk specifically for Google Docs? Any > other web application can be potentially broken, as they may rely on > Cache-Control headers to work properly in any navigation. Cache-Control is about the HTTP disk cache, and works. There is no documented impact of the Cache-Control header on the back/forward cache.
It seems to me that RFC 7234 doesn't make a difference between disk and memory caches. And CachedResourceLoader (rightfully) takes them into account, though it's not a disk cache.
If there is a consensus that back/forward cache should be exempt from caching rules[*], IMHO it needs to be codified somewhere in Web Platform standards so that authors could design their pages accordingly. [*]given that Google product doesn't assume this it seems to me there isn't)
(In reply to Konstantin Tokarev from comment #14) > If there is a consensus that back/forward cache should be exempt from > caching rules[*], IMHO it needs to be codified somewhere in Web Platform > standards so that authors could design their pages accordingly. > > [*]given that Google product doesn't assume this it seems to me there isn't) Back/Forward cache isn't like a "cache". When a page is put into back/forward cache, all page's states are still here. It's as if the page never navigated away. So it's not really a cache in the sense of the browser saving sub-resources & re-loading a web page using those cached resources. For web pages, it behaves as if the user hadn't navigated away / never been closed.