Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consider how Client API should behave with bfcache #1038

Open
wanderview opened this issue Dec 19, 2016 · 8 comments

Comments

@wanderview
Copy link
Member

commented Dec 19, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Apr 3, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2017

  • 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

This comment has been minimized.

Copy link
Member Author

commented Apr 3, 2017

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

@jakearchibald

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Apr 13, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Sep 15, 2019

For TPAC:

@jakearchibald

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2019

Notes:

  • We should spec evicting items from bfcache if controller would change.
  • Ensure clients.match doesn't return items from bfcache.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.