Clients.claim() does not deal with a client already controlled by another registration

[nikhilm]

Consider a page located at /a/b/c/d.html

1. Register SW for /a
2. Load d.html -> d is controlled by /a
3. Register another SW for /a/b. Now d is still controlled by /a but the 'matching registration for scope' will be '/a/b'
4. Register another SW for '/a/b/c'. This SW calls claim() in onactivate.
   At this point, we should first run Handle Service Worker Client Unload steps with the client, then change the client's active worker. The former is not being done right now.

[jungkees]

.claim() claims all the clients whose origin is the same origin to the service worker the method is running on to be immediately controlled by it as long as the service worker is an active worker.

In the example, the registration for '/a', for '/a/b' and for '/a/b/c' are three different registrations. And at step 4, the service worker in the registration for '/a/b/c', as it's been an active worker already, immediately becomes the controller for d.html which was being controlled by the registration for '/a' by this time.

I don't see a reason Handle Service Worker Client Unload should be run here. Please let me know if I'm misunderstanding your question.

[jakearchibald]

In @nikhilm's example, imagine the registration with scope /a has an active worker and a waiting worker. The waiting worker cannot become active until all its clients are gone. It only has one client, /a/b/c/d.html.

• New registration with scope /a/b/c is created
• SW for /a/b/c activates
• SW for /a/b/c calls clients.claim()
• /a/b/c/d.html is now controlled by the registration at scope /a/b/c

This means the registration with scope /a now has no clients, so its waiting worker should become active. As @nikhilm says, calling Handle Service Worker Client Unload before 3.1.3.1 should make this possible.

[nikhilm]

👍 @jakearchibald

[jungkees]

Gotcha! Thanks!