Back-forward cache: Specifying ineligibility?

[rakina]

As mentioned in #5744 and #5748, the factors that affect a page's eligibility to be preserved in BFCache differs between browsers, but some are consistent (e.g. Cache-control: no-store).

I think the current spec allows "preserving" Documents implicitly by having Document objects associated with session history entry, which will be used during history traversal.

I wonder if it makes sense to specify that a Document should never be preserved/re-used on history traversal, or if that falls into "implementation details" territory? The spec change should be minimum, and with that we can remove a lot of ambiguity on "what should happen with this if the Document/browsing context associated with it is no longer active?" on some of the things that will make a page ineligible for bfcache (example).

[rniwa]

In general, we don't want to limit the eligibility of page cache because we want to expand it as much as possible for better user experience. @cdumez

[domenic]

I think the current spec allows "preserving" Documents implicitly by having Document objects associated with session history entry, which will be used during history traversal.

Indeed, this is the case.

Note also that the spec currently has a salvagable state, which if you follow the links around, is used to basically disable bfcache whenever unload handlers are triggered. From what I understand browsers are intentionally violating this part of the spec these days, and we should probably clean that up...

I wonder if it makes sense to specify that a Document should never be preserved/re-used on history traversal, or if that falls into "implementation details" territory?

Although I tend to agree with @rniwa in the general case, I wonder about the case of explicit web developer opt-outs. #5744 has some discussion in that regard (although it went in a different direction). I wonder if at least Cache-Control: no-store should also become a cross-browser interoperable way of achieving ineligibility. @rniwa, @cdumez, any thoughts there?

The spec change should be minimum, and with that we can remove a lot of ambiguity on "what should happen with this if the Document/browsing context associated with it is no longer active?" on some of the things that will make a page ineligible for bfcache (example).

I'm not quite clear on what spec change you are proposing. Are you concretely suggesting, per the linked document, IndexedDB and Web Locks make pages bfcache-ineligible? If so, I think it'd be good to discuss those specifically, and get all the implementers' perspectives.

[rakina]

Yeah I guess I'm mostly concerned about the specific case of Cache-Control: no-store. If we think it should always guarantee ineligibility, then we should spec it. If we think that it might change in the future (I think Safari was trying to remove it from being an opt-out, before changing it back), maybe we should make it clear also?

For the explicit bfcache opt out discussed in #5744, it looks like the direction the API is going towards currently is "remove currently-alive documents from history entries", so we can spec that without this.

For APIs like IndexedDB, I was thinking that if we already have a concept of "bfcache ineligibility", then we can add a handwavy note like "If the page has existing connections/relations that might affect other pages, such as an IndexedDB connection, the user agent might consider the page as ineligible for bfcache" . But maybe that won't really make sense/won't really help? Maybe as Domenic mentioned it's better to talk about each API separately and clarify how they would work (or not) when bfcached..

[domenic]

Yeah I guess I'm mostly concerned about the specific case of Cache-Control: no-store.

Makes sense. I take it that Chrome plans to, for the foreseeable future, treat this as an opt-out for bfcache, and would support writing that opt-out into the spec? I'm curious to hear from Safari and Firefox in that case; if it's something everyone agrees on, we could at least make it a "should", if not a "must".

But maybe that won't really make sense/won't really help?

I think it makes sense, but indeed, it only helps a minimal amount. Since the UA gets to do whatever it wants, adding such spec text wouldn't improve interop or provide strong guidance for browsers to rally around. Instead it would just make the spec a bit more understandable, whereas right now it's a mystery as to why a browser would or would not put things in bfcache.

Increasing understandability in this way is a reasonable goal, and I would be fine reviewing/merging PRs of that sort. But I think the higher impact would be from specifying how things work when bfcached.

[domenic]

@rakina's changes in #5889 made me realize the spec already prohibits bfcaching in some cases (via the "salvagable" mechanism): https://html.spec.whatwg.org/#dom-pagetransitionevent-persisted-dev has a non-normative list (which #5589 modifies).

If folks think that list is too restrictive, we may want to spin off separate issues (e.g., if browsers want to figure out a way to bfcache pages with open WebSockets). Alternately, it serves as an easy place to expand, if we want to make Cache-Control: no-store, or IndexedDB, or similar, prevent bfcache on a spec level.

[rakina]

But I think the higher impact would be from specifying how things work when bfcached.

Yeah I agree. On this topic, recently there's some interest in making things like WebRTC work with bfcache (no public threads yet though). To help spec this, I think we need to have "before-getting-bfcached cleanup steps" so that we can say that we're pausing connections etc. Do we have something like this already? If not maybe we can modify and reuse "unloading document cleanup steps" for this (this also helps remove one more usage of "unload" :) )

the spec already prohibits bfcaching in some cases (via the "salvagable" mechanism): https://html.spec.whatwg.org/#dom-pagetransitionevent-persisted-dev has a non-normative list (which #5589 modifies).

Right, so we have a way to specify ineligibility nicely, yay \o/

BTW, looks like we're summarizing cases where we modify the "salvageable" bit all over the spec in the note for the "persisted" bit. Perhaps we should move it somewhere closer to unload/"before-getting-bfcached cleanup steps" when we have that.

(Also, on the WebSockets part specifically, I found #1931)

[fergald]

Cache-Control: no-store is the largest single blocking reason for pages not entering bfcache on chrome.

Some questions

• Assuming we provide a way to clear a site's entries (as discussed in Add an API to opt-out of back-forward cache? #5744), should a page be able to avoid BFCache?
  • If yes: should it be
    • no-store stops all caching including bfcache?
    • no-store allows bfcache and pages need to set something else or something further to avoid bfcache?
    • something orthogonal to no-store so that you can stay out of BFCache even though you are cached on disk?I think nobody wants this, it's just here for completeness.
  • If no:
    • then no-store should be clarified to say it doesn't prevent BFCache (once we give sites enough control).
    • how can a site express "no-store but bfache is ok"?

Based on https://github.com/httpwg/http-core/pull/545/files, it seems like it could be OK for BFCache to be used on a no-store page if we gave enough control. However the current behaviour of blocking BFcache is long-established, so changing it at this point might fail on the "apparent" part of that or at least we have to be careful and vocal when changing this.

[domenic]

In issues like #7189 the Chrome team has started to make proposals for concrete behaviors. I'd like to get a sense from other implementers to what extent they are interested in interoperability and web platform predictability here, to figure out whether such concrete proposals should end up in the spec or in Chrome-specific documentation.

In #5879 (comment) @rniwa says

In general, we don't want to limit the eligibility of page cache because we want to expand it as much as possible for better user experience. @cdumez

which seems negative on this interop project.

In general on the Chrome team, we'd prefer to have thorough specifications and tests for the behaviors we ship, including bfcache. But if there's not much appetite from the implementer community for that, that would be good to know.

[cdumez]

In WebKit/Safari, we leverage the back/forward cache almost unconditionally. Therefore, adding conditions for when a page is eligible for caching or not will decrease our cache hit. For example, I think Blink doesn't leverage the back/forward cache when a window has an opener but WebKit does. Aligning with Blink here seems like it would regress our perf.

[fergald]

@cdumez there was a thread on exactly that case. What does WebKit do if the opener modifies the BFCached document? There does not seem to be any reasonable behaviour for that case (the document may have MutationObservers but they can't run). Even evicting in that case leaves the opener with a suddenly-null window reference. I realize that in many cases this will not happen, so you can get away with most of the time.