Bug 208381 – Add quirk to disable to back/forward cache on docs.google.com

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Chris Dumez]

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).

[Chris Dumez]

<rdar://problem/59893415>

[Chris Dumez]

Created attachment 391990 [details]
Patch

[Ryosuke Niwa]

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?

[Chris Dumez]

(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.

[Ryosuke Niwa]

(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?

[Chris Dumez]

Created attachment 392034 [details]
Patch

[Chris Dumez]

(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.

[Ryosuke Niwa]

Comment on attachment 392034 [details]
Patch

Looks good to me.

[Chris Dumez]

Comment on attachment 392034 [details]
Patch

Clearing flags on attachment: 392034

Committed r257714: <https://trac.webkit.org/changeset/257714>

[Chris Dumez]

All reviewed patches have been landed.  Closing bug.

[Konstantin Tokarev]

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.

[Chris Dumez]

(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.

[Konstantin Tokarev]

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.

[Konstantin Tokarev]

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)

[Ryosuke Niwa]

(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.