consider how Client API should behave with bfcache

[wanderview]

In Firefox we have a back-forward cache (bfcache). When in effect you get pageshow and pagehide events with the event.persisted attribute set to true. I believe safari has this mechanism as well.

How should we handle the Client for windows that go into and out of the bfcache?

My current plan is:

1. Environments in the bfcache will not be exposed to Clients.matchAll().
2. An environment leaving the bfcache will retain its original client ID.
3. Calls to postMessage() while the environment is in the bfcache will be queued and delivered if the page comes out of bfcache.

The postMessage() thing might be too expensive memory-wise, but I'd like to try it.

[jakearchibald]

• The bf cache should be purged if the active worker changes

[jungkees]

Do we have bf cache spec'd in HTML? If so, we might want to match service worker registration again from there when a client is restored.

[jakearchibald]

• In Firefox, an attempt to broadcastchannel to a page in the bfcache will remove it from the bfcache
• This behaviour seems weird at first, but I kinda like the guarantees it gives

[wanderview]

To clarify last comment, if postMessage() tries to deliver to a bfcache'd Client then its evicted from the bfcache.

[jakearchibald]

Same goes if the client's controller would change. Eg a service worker upgrade would cause older bf clients to evict, a clients.claim() would evict a client from the bfcache if its controller would change too.

[KenjiBaheux]

On Chrome, we do not have a bfcache.
Instead we do a navigation but with a special Load-Preferring-Cache flag which lets Chrome re-use assets in the HTTP cache regardless of staleness (with a few exceptions). This behavior is also used for the Tab Restore flow.

With a Service Worker involved, we think it would be best to allow the developers to identify which user journey is playing out and decide for themselves if they want to fallback to the default behavior or use a custom behavior on a per resource request basis.

I'm currently trying to piece out a solution from the current SW/Fetch specs.
Will report back soon.

Side-note: if this use case is reasonable and can (has to) be done in Chrome, then should developers be able to override bfcache and control the user experience via their service worker with other UAs?

[jakearchibald]

For TPAC:

• This is spec'd more than I thought.
  • https://html.spec.whatwg.org/multipage/history.html#the-session-history-of-browsing-contexts.
  • https://html.spec.whatwg.org/multipage/browsing-the-web.html#traverse-the-history.
• We should agree on a behaviour, spec it, and write tests.
• How do you write tests for this? Manual? Or navigate and iframe around?

[jakearchibald]

Notes:

• We should spec evicting items from bfcache if controller would change.
• Ensure clients.match doesn't return items from bfcache.

[KVPasupuleti]

Hey, bfcache is now enabled for all Chrome users across Desktop and Mobile from v96.x

Check out this article by web.dev from here