Specify bfcache behavior with proper tests

[saschanaz]

I intend to add a bfcache test where any active lock/request prevents caching, matching the current Chrome Dev 96 behavior.

Is this something you want to change or are you okay with the current Chrome behavior? To me it sounds reasonable enough, and in that case I think we should at least add a note about it, if it's not something can be specced.

[inexorabletash]

Yes, thank you! I think we're okay with the current Chrome behavior.

[saschanaz]

@inexorabletash In my observation Chrome disables bfcache at the first lock request and never enables it again, is this something Google wants to enhance or does it actually enable bfcache again?

[inexorabletash]

I've reached out to our BFCache folks for an opinion.

[inexorabletash]

Per @rakina - ideally we'd only make pages disable bfcache when it is necessary, so we could consider pages that have released all locks to be eligible for bfcache again.

So... might be a bug in Chrome (I haven't tested myself!). But let's not spec (or codify via WPT) an assumption that Chrome's current behavior is desired.

[saschanaz]

Cool. Gecko also wants to enable bfcache again when eligible, and I'm planning to add tests for that. It seems bfcache tests are marked as optional (by using assert_optional_implements) so I guess doing so shouldn't flag Chrome behavior as invalid, at least for now.

[fergald]

Yeah, it's not a bug in Chrome in the sense that it's perfectly fine to block BFCaching for any reason. It's not the situation we want long-term though, we just took the fastest path to correctness, knowing that we were over-blocking with a plan to come back and optimise.

As for the test, yes, it should give PRECONDITION_FAILED, please make use of the helpers, e.g. assert_bfcached

@hiroshige-g who is also adding BFCache tests FYI.

[saschanaz]

From https://github.com/WICG/web-locks/issues/78#issuecomment-920543922

Coincidently, the following guidance just got merged into the TAG design guidelines: https://w3ctag.github.io/design-principles/#support-non-fully-active

It seems this also covers bfcache which should help us spec the behavior.

[hiroshige-g]

Great. FYI There are also some docs about writing bfcache/navigation tests at

• https://github.com/web-platform-tests/wpt/blob/master/html/browsers/browsing-the-web/back-forward-cache/README.md
• https://github.com/web-platform-tests/wpt/blob/master/common/dispatcher/README.md

and some more test examples under codereview (they will be refactored before landing though):

• https://chromium-review.googlesource.com/c/chromium/src/+/3198456
• https://chromium-review.googlesource.com/c/chromium/src/+/3198457
• https://chromium-review.googlesource.com/c/chromium/src/+/3201011
• https://chromium-review.googlesource.com/c/chromium/src/+/3222281

[saschanaz]

Another FYI, WPT now has some bfcache tests specifically for Web Locks, e.g. https://wpt.live/web-locks/bfcache/held.tentative.https.html

[rakina]

It seems like we have a WPT already. Is there anything that needs to be updated on the spec side for this? BTW there's a guide on how to handle non-fully active documents (which includes BFCached documents).

[saschanaz]

Is there anything that needs to be updated on the spec side for this?

It currently says nothing about blocking bfcache, so maybe we should add some?

It seems setting salvagable to false does that work, but in this way we can't safely set it true again.

@annevk, is salvagable the right tool to use here?

[annevk]

Yeah, you'd set salvageable to false during the unloading document cleanup steps.

cc @domenic