Back-forward cache meta-bug

[rakina]

Since there's a lot of separate discussions related to back-forward cache, I think it might be useful to have this meta-bug to track them to keep people who are interested in it aware of all the relevant discussions (inspired by @domenic's focus meta-bug :) ).

API additions

• Add an API to opt-out of back-forward cache? #5744

General web-exposed behaviors

• Back-forward cache: Specifying ineligibility? #5879
• back-forward cache: specify interaction with unload & beforeunload #5748
• Back-forward cache: Restoring focus #5878
• Clarify history.pushState/replaceState behavior with history navigation, bfcache #6207
• Should last activation timestamp be reset after navigation? #6588
• Define back-forward cache behavior in terms of Navigation Timing reporting #6563
• gamepadconnected/disconnected events & non-"fully active" documents w3c/gamepad#149
• Allow certain tasks to run even when document is not fully active? #6699
• Deal with not fully active documents w3c/geolocation#78
• Handle non-fully-active documents w3c/permissions#162
• Interactions with the BFCache? WICG/file-system-access#319
• Interactions with the Back-forward cache? WICG/js-self-profiling#53
• Determine interaction with back forward cache w3c/webtransport#326
• Investigate "salvageable" and WebSocket interaction #1931
• Make a way to listen to "fully active" state changes #8872

BFCache eligibility/eviction

• How should BroadcastChannel and BFCache interact? #7253 and Add steps to destroy documents that are ineligible for receiving message when posting message through broadcast channel #8972
• How should IDB connections and outstanding IDB transactions behave when a page enters back/forward cache? w3c/IndexedDB#381
• Interactions with the BFCache fs#17
• How does ServiceWorker interact with non-"fully active" documents? w3c/ServiceWorker#1594

Browsing context/browsing context group change

• Back-forward cache: browsing context change & "fully active" concept #5877
• Impact of browsing context group switch during navigation #5350
• Changing the session history spec to converge on historical & modern browser behaviour #5767
• specifying BFCache interactions with window.open and browsing context groups #6858

WPT

• Policy for "Back/Forward Cache" (aka "bfcache" or "Page Cache") web-platform-tests/wpt#16359
• Specify bfcache behavior with proper tests w3c/web-locks#81

Related APIs

• https://github.com/fergald/explainer-bfcache-ccns
• Exposing back/forward cache blocking reasons to sites #7094

Also, the Chrome BFCache team made a document that lays out some behavior differences between Chrome, Firefox, and Safari's bfcache: https://docs.google.com/document/d/1JtDCN9A_1UBlDuwkjn1HWxdhQ1H2un9K4kyPLgBqJUc/edit?usp=sharing. The doc is probably incomplete, and some differences mentioned in the doc have no spec issues filed at the moment. Feel free to open issues and I'll add to the list. Let me know if there's anything I'm missing :)

cc people in previous threads @annevk @smaug---- @mystor @cdumez @beidson @hober @altimin @xharaken @fergald @geoffreygaren

[zcorpan]

#6556 mentions that document.open() prevents bfcache in chromium (IIUC)

#6207 (comment) suggests cache-control: no-store prevents bfcache. (Also see https://web.dev/bfcache/#minimize-use-of-cache-control-no-store )

[fergald]

@zcorpan

#6207 (comment) suggests cache-control: no-store prevents bfcache. (Also see https://web.dev/bfcache/#minimize-use-of-cache-control-no-store )

A currently implemented, yes but we are trying to change that with https://github.com/fergald/explainer-bfcache-ccns

[rakina]

Thanks @zcorpan, I've added a list of issues related to BFCache eligibility/eviction in the original post. It would be great if we can get the open issues, discussions and PRs around those resolved, e.g. #8972 for BroadcastChannel.

#6556 mentions that document.open() prevents bfcache in chromium (IIUC)

In Chrome's implementation, I don't think document.open() affects BFCache eligibility (intentionally, at least). I think there's been a bunch of changes around history too after that issue, maybe @domenic can comment more here (I'll try to repro soon too if needed)

[zcorpan]

Is WebKit interested in changing cache-control: no-store such that it doesn't prevent bfcache?

[cdumez]

Is WebKit interested in changing cache-control: no-store such that it doesn't prevent bfcache?

We are. As a matter of fact we already tried. However, we had to revert our change because of complaints from banks (You log out of your bank account, then press back and still see your bank account). What's the plan to deal with this? (The clear-site-data HTTP header?).

[zcorpan]

Making clear-site-data: cache (or *) prevent bfcache makes sense to me and could be a replacement for banks. I see you already implemented that in WebKit in WebKit/WebKit#4617

Gecko removed "cache" in https://bugzilla.mozilla.org/show_bug.cgi?id=1671182 but I'll file a new bug to implement it. Edit: https://bugzilla.mozilla.org/show_bug.cgi?id=1838506

[zcorpan]

(I noticed now that privacycg/storage-partitioning#11 is still open re clear-site-data: cache)

[fergald]

Re: CSD and cache-control: no-store (CCNS)

We (Chrome) think that CSD should remove BFCache pages and recently impllemented it but I don't think it's enough to just allow all CCNS pages into BFCache. We have been working on a cautious first step to allow caching pages with CCNS. The explainer is here. It includes CSD additional mitigations. An earlier version of this was proposed here. We would appreciate feedback.

I'll post some info on why just enabling CSD and then caching is problematic.

Logging out of a site doesn't necessarily involve a network request to that site. Apps that log in/out using e.g firebase or other federated logins can log in/out without any network request going to the app's site. Logging out with federated login is just a matter of discarding your access token.

Our biggest concern is that we are trying to change a very old behaviour. CCNS used to be documented (on MDN, I think) as the way to stop BFCache and it's still given as an answer on stack exchange etc. If we just provide a way to fix it (e.g. CSD) and then go ahead and start BFCaching, every problematic site is a problem until they notice and fix it.

We know that we can be more cautious without much cost. Our previous experiment observing cookies told us that we can turn about 50% of cache misses into hits if we evict whenever any cookie for that site changes and 95% if we only consider HTTP-only cookies. Our current plan is much more cautious than that because it also uses fetch/XHR as a signal. We don't yet know what fraction of CCNS pages it will unblock.