Policy for "Back/Forward Cache" (aka "bfcache" or "Page Cache")

[jugglinmike]

Firefox and Safari implement a cache which drastically alters the behavior of history.back and history.forward. Chrome is experimenting with a similar feature.

The optimized behavior is at odds with at least one test in WPT: websockets/unload-a-document/002.html (latest results from wpt.fyi). It's difficult to say how many more tests are affected by this. There appears to be just 80 references to history.back and history.forward, and that may be a fair upper bound.

Judging only from the issues where "bfcache" has been mentioned, it seems as though we're willing to accept tests concerning this behavior as long as they do not fail in non-supporting browsers. I can't find any discussion about the policy itself, hence this issue.

It doesn't seem like we can support this optionally since contributors need to know what will happen if they invoke history.back in a test.

If we assume it is present, we'll need to update the relevant tests and instruct authors to circumvent the behavior when it's unwanted. If we assume it is absent, we should include instructions/automation on disabling it whenever possible. In either case, we should make mention of this in the documentation on the infrastructure's assumptions.

[hiroshige-g]

This kind of debugging against heuristics might be more likely in the wild rather than in writing tests, so web developers might have experiences/opinions... not sure though.

As for testing, so far I haven't encountered flakiness around BFCache eligibility, and disableBFCacheForThisPage is probably easily polyfillable, so I expect the impact on test framework design would be limited.

[domenic]

I don't think we should introduce something to say "make bfcache deterministic" at the start of every bfcache test, that should just be the default for all WPT tests.

I don't think this is realistic. I run WPTs in Chrome Canary with no flags, or just the usual Chrome stable that I run. The point of WPTs is to test browsers as they are, not browsers in a special mode. Indeed, from what I understand wpt.fyi (and the CI for the WPT repository) run in a no-flags mode.

If a test requires a browser to be in a special mode, then it should communicate that to the browser in some way, e.g. using WebDriver.

[fergald]

I don't think this is realistic. I run WPTs in Chrome Canary with no flags, or just the usual Chrome stable that I run. The point of WPTs is to test browsers as they are, not browsers in a special mode. Indeed, from what I understand wpt.fyi (and the CI for the WPT repository) run in a no-flags mode.

BFCache is observable, including outside of tests intended for BFCache. We had to rewrite some of chrome's pre-existing web tests to cope with BFCache. Having observable behaviour controlled by heuristics means that all tests that navigate are potentially subject to this problem (whether they know it or not).

So providing an API won't fix everything but I do see the benefit of not running in a special mode. I think we can wait and see if this problem ever occurs before trying to fix it.

Note, chrome's dev-tools will tell you whether/why a navigation was cached, so that will help.

[domenic]

This problem has already occured: some of the wpt.fyi preview results generated by CI on the above PR fail in Chrome (and some succeed), since the wpt.fyi CI does not know to run Chrome in a special mode.

[fergald]

This problem has already occured: some of the wpt.fyi preview results generated by CI on the above PR fail in Chrome (and some succeed), since the wpt.fyi CI does not know to run Chrome in a special mode.

I think the only special thing we do right now is disabling the timeout and that should be irrelevant.

It's more likely that that bot is in an group that just doesn't have BFCache at all. No beta or stable desktop chrome has it yet, so it is essentially like any unreleased feature right now.

[domenic]

The bot runs with experimental web platform features so I don't think that's what causes it. I suspect it's the timeout; it runs many tests in a row and it'd be easy to trigger such a timeout, IIUC?

[fergald]

OK, so if they're enabling BFCache as an experimental feature then I imagine it's got the default timeout (15s whereas real users who are in our rollout groups get 180s.

Regardless of these tests, we should update the default timeout to 180s so that enabling the feature gets people a useful experience and also in the long-term, drop the need to send a timeout in our configs.

[jgraham]

It's not really true that we run browsers in a totally unmodified state from what ships; it's pretty common to have to set some prefs to get reliable test behaviour. So I don't think that it's totally unreasonable to supply a flag/pref/etc. that disables bfcache eviction based on heuristics. I also think it would be quite reasonable to have an API (in testdriver or as a test-only API in the DOM) to clear the bfcache, if that helps get a clean slate (I think we typically run each test in a fresh top-level-navigable already, so it might not make much difference).

[hiroshige-g]

The bot runs with experimental web platform features so I don't think that's what causes it. I suspect it's the timeout; it runs many tests in a row and it'd be easy to trigger such a timeout, IIUC?

IIUC BFCache is not included in the experimental web platform features (see https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/runtime_enabled_features.json5;l=246?ss=chromium) and the failures are expected for me (due to lack of --enable-features=BackForwardCache flags). The test are passing on virtual/bfcache tests (which sets --enable-features=BackForwardCache) on Chromium bots and fails on non-virtual tests (e.g. https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/701591/overview).