consider firing a "clientcontrolled" event on ServiceWorkerGlobalScope
Nobody has claimed this yet.
- Dominant language
- Bikeshed
- Stars
- 3.6k
- Forks
- 324
- Avg merge
- 14d 22h
- Merged PRs (30d)
- 1
Description
I'd like to tentatively propose that we fire a clientcontrolled event on the ServiceWorkerGlobalScope when that worker begins controlling a client. There could also be a clientuncontrolled event, but that is less important to me at the moment.
This could enable service workers to maintain and track state more specifically than they can do today. Right now SWs can infer which clients are going to be controlled from FetchEvent, but its really an approximation. Some documents will fail to load or be closed. Exposing these events would provide better tracking.
My real reason for suggesting this, though, is to handle a corner case with bfcache. I realize firefox might be the only browser to implement bfcache, so this may not be a strong argument. But consider the following situation:
- Document A is controlled by SW X.
- User navigates the window and A goes into the bfcache. A also becomes uncontrolled at this point so history items don't block updates, etc.
- SW X then does a Clients.matchAll() and see A is gone. It cleans up Cache objects and state A was using.
- User clicks the back button and A comes back out of the bfcache. Our current plan is to make it controlled again with the same client ID.
- SW X does a Clients.matchAll() and suddenly sees A again, but it never saw a FetchEvent. SW becomes confused and goes to cry in the corner.
Some options we considered, but currently don't like:
- Disable bfcache for documents that are controlled. This would effectively disable bfcache for huge swaths of the internet; Facebook, Pinterest, etc.
- Expose documents in bfcache to Clients.matchAll(). This would be super confusing as the list just grows as the user navigates. Also, things like Client.focus() would not make sense.
- Don't re-control documents when they come out of bfcache. This would make it look like a new uncontrolled client appeared which is normally possible via a hard refresh. This would expose a difference between browsers, though, because history.back() would result in a controlled document in chrome, but not firefox.
I'm open to suggestions, but the clientcontrolled event would have wider application and would let the SW behave sensibly to this case.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the ServiceWorkerGlobalScope and Clients.matchAll behavior described in the issue, then trace the bfcache scenario and the listed alternatives. Done would require settling the event's purpose and lifecycle semantics, including how it handles documents returning from bfcache, before the behavior can be specified.
Written by the indexing model from the issue text.
Assessment
- Domain
- api, web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100