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.

[jugglinmike]

I'd prefer to assume absence because the feature isn't standardized, but I don't know if/how it can be disabled in the browsers we support.

[gsnedders]

In principle, the bfcache is just an optimisation that's only sorta observable. I think @annevk was planning on updating how HTML sorta acknowledges the existence of bfcaches in plenty of browsers to actually be more accurate (because with Blink implementing a bfcache we'll then have every major browser having one).

We'll want to run some tests with the bfcache enabled (though it's a bit awkward, like testing any caching behaviour, given eviction is implementation defined). Are there any we want to run with it disabled? Testing behaviour that isn't actually in the shipped configuration isn't that useful.

[annevk]

It is standardized, no? It's the pagehide / pageshow events, the salvageable state on documents, session history entries being able to point directly to Document objects, the fully active concept, etc. It might not be great, but it's better than a lot of things.

[jugglinmike]

In principle, the bfcache is just an optimisation that's only sorta observable.

It's hard to discuss observability in relative terms. More concretely: the feature directly undermines the expectations of the test I referenced above. That test sets window.location to trigger navigation to another document. The new document invokes history.back() and expects the following:

• the scripts in the first document are evaluated a second time
• the timers created from the prior evaluation have been destroyed

These may not happen if the UA is using a bfcache. Safari 12.0 fails for this reason.

My first suggestion is that we document an assumption: "history.back() and history.forward() do not trigger a navigation" and update tests that assume otherwise to use alternate methods (e.g. setting window.location).

My second suggestion is that we document as assumption: "The browser does not implement a so-called 'bfcache'" and take steps to ensure it is disabled in each browser.

Although I initially favored the second suggestion, @annevk's input that there is spec prose governing the behavior makes the first suggestion seem more appropriate.

[annevk]

I don't understand what documenting an assumption means. history.back() may trigger a navigation if there's no Document object on the prior session history entry, as per https://html.spec.whatwg.org/multipage/browsing-the-web.html#traverse-the-history.

[jugglinmike]

@annevk I'm referring to the "Assumptions" document in the project's guide for writing tests. For the purposes of consistency, I think we have to instruct test authors to assume that navigation will not occur because the presence of the Document in the session history entry (and thus the possibility of a navigation) is at the discretion of the UA https://html.spec.whatwg.org/multipage/history.html#the-session-history-of-browsing-contexts

[annevk]

That document reads more to me like "expected configuration", not "assumptions". Whether back() navigates or swaps with an existing Document object is quite different from that. It's much more of a cache thing which we shouldn't expect anything of in general, but might be okay within a set of delineated tests.

[jugglinmike]

@annevk Essentially, I want to update the referenced test to set window.location instead of invoking history.back. That alone will make the test behave consistently in Safari, but future tests could just as easily make the same mistake.

The reason I've raised this in terms of WPT policy is that the flaky test seems like a symptom of a larger problem: the bfcache behavior can subvert the expectations of test authors. I agree that authors should not assume a cache is in use. They also shouldn't assume a cache isn't in use. The recommendation I want to make is "don't use history.back or history.forward for navigation because we can make no guarantees about how the browser will respond."

Maybe the "Assumptions" document isn't the best place to put this, but I still feel that this needs to be said somewhere. Simply fixing the test seems inconsistent--we'd be acknowledging the use of those APIs as a bad practice without telling other folks to avoid it.

[annevk]

So looking at the test I think it's actually testing bfcache behavior (it's affected by WebSocket), so I'd be opposed to changing it. This might show a bug in Safari.

[jugglinmike]

Can you elaborate on what text you feel the test is verifying?

[annevk]

Well, that WebSocket causes unsalvageable to be set and that therefore going back cannot ever go to a cached ddocument.

[jugglinmike]

Ahah, the unloading document cleanup steps:

2. For each WebSocket object webSocket whose relevant global object is window, make disappear webSocket.

   If this affected any WebSocket objects, then set document's salvageable state to false.

However, in that test, the document is being unloaded from the WebSocket's close event handler, which is nested in the open handler. In other words, the WebSocket connection has been established and the closing handshake has been started, so "make disappear a WebSocket" does nothing.

Since the salvageable state is not set to false, the presence of the Document in the session history remains at the discretion of the UA. If that's right, then Safari's flaky behavior is permissible.

[annevk]

Interesting, though that would mean it's showing a Firefox bug as for some reason Firefox does seem to set salvageable to false, right?