Add an API to take over uncontrolled pages (or pages controlled by another service worker)

[jakearchibald]

This used to be part of installEvent.replace(), but we've separated out the skip-waiting part into self.skipWaiting, but we still need the other part.

Loosely, this would:

1. If this worker isn't active, either wait or reject (TODO: not sure what's best yet)
2. For each client
   1. Let registration be the result of "Match Service Worker Registration" for that client
   2. If registration is not the registration already in use by the client:
      1. If registration is this serviceworker's registration:
         1. Make the client use registration, fire controllerchange event
3. Resolve promise with undefined

Need to have a think about step 1. Also, maybe it should resolve true/false depending on if anything actually changed.

@slightlyoff suggested clients.claim() as a API name/location, which works for me.

[KenjiBaheux]

We've got feedback from web developers that this ability would be useful. Was there any further discussion elsewhere?

Regarding step 1. did you have time to think about it? Rejecting feels like the most malleable option.
Also, understanding whether or not something actually happened seems useful.

[jungkees]

Specified Clients.claim(): aeee6b9. A non-active worker's claim rejects for now.

[KenjiBaheux]

Thanks!

On top of rejecting for non-active SW, let me note that you opted for returning undefined

cc/ @jakearchibald @slightlyoff in case there has been any discussion on those 2 aspects.

[KenjiBaheux]

Tracked via http://crbug.com/450106 for Blink

[seanlong]

There's a question raised by @michael-nordman in Blink .claim() impl code review:
"Although, that seems like it's probably an oversight. It's odd that Claim() uses
ever so slightly different logic to pick a registration than that used by
HandleFetch() for a navigation?"

Should the step Let registration be the result of "Match Service Worker Registration" for that client filter out registrations without an active worker?

[jakearchibald]

@KenjiBaheux

On top of rejecting for non-active SW, let me note that you opted for returning undefined

What's the alternative?

@seanlong @michael-nordman

Should the step Let registration be the result of "Match Service Worker Registration" for that client filter out registrations without an active worker?

Can you give me a situation that would produce a different result?

If the returned registration is unequal to the calling SW's registration, it'll be discarded in the next step. If the returned registration is equal to the calling SW's registration, but there's no active worker, wouldn't we have already failed in step 1?

Or, is the issue that states may have changed between step 1 and 3.1.3? We should probably ensure that the calling worker is still active once we get to 3.1.3, and reject if it isn't.

[seanlong]

Can you give me a situation that would produce a different result?

If the returned registration is unequal to the calling SW's registration, it'll be discarded in the next step. If the returned registration is equal to the calling SW's registration, but there's no active worker, wouldn't we have already failed in step 1?

The situation happens when a registration which only has a installing worker is a longer matched registration than the calling SW's registration. The calling SW will not claim in this situation.

Currently in Blink impl, navigation fetch will choose the longest matched registration which has a active/waiting worker(seems different from sepc [[Handle Fetch]] 12.2 & 12.3, if the longest matched registration only has a installing worker it will not be used). Not sure whether the .claim() should behave the same?

[jungkees]

If the returned registration is unequal to the calling SW's registration, it'll be discarded in the next step. If the returned registration is equal to the calling SW's registration, but there's no active worker, wouldn't we have already failed in step 1?

Right. The returned registrations without an active worker are ignored in step 3.1.2.

Or, is the issue that states may have changed between step 1 and 3.1.3? We should probably ensure that the calling worker is still active once we get to 3.1.3, and reject if it isn't.

Getting to 3.1.3 already ensures the calling service worker is still an active worker. The only chance an active worker becomes not active would be to be terminated by the user agent, which effectively aborts the script currently running in the worker.

[jungkees]

The situation happens when a registration which only has a installing worker is a longer matched registration than the calling SW's registration. The calling SW will not claim in this situation.

This sounds a bit tricky, but to me the currently specified behavior seems more reasonable. The fact that a client is matched to a certain registration means the client will be controlled by the registration's worker when it becomes active. (rather than making it to use the shorter matched registration already effective.)

[KenjiBaheux]

@jakearchibald I might have misunderstood but I think the alternatives were mentioned in your first post:

If this worker isn't active either wait or reject (TODO: not sure what's best yet)

and

Also, maybe it should resolve true/false depending on if anything actually changed.

[wanderview]

Tracked in gecko here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1130684

[jakearchibald]

@KenjiBaheux oh, yes, sorry! Yeah, I'm happy with rejecting if not active & resolving undefined.

[jungkees]

Closing.