1311205 - ServiceWorkerRegistration.active not set at time of activate event

Status: RESOLVED DUPLICATE of bug 1113522

(Core :: DOM: Service Workers, defect)

Description

[ben last]

Within the handler for the ServiceWorker 'activate' event, the currently active worker (at 'self.registration.active') is 'null'. If I understand the logic defined at https://www.w3.org/TR/service-workers/#activation-algorithm the 'active' reference should be set at the time the activate event is fired.

I expected that self.registration.active would be the worker that is receiving the activate event (our code is looking for the URL of the worker that has just been activated, and expects to find it at self.registration.active.scriptURL).

Chrome shows the expected behaviour when we run the same code. The activate event handler is able to reference the worker via the 'registration.active' reference.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Unfortunately we haven't exposed the ServiceWorker object in the worker context yet.  See bug 1113522.

We definitely need to fix this, but I'm curious what your particular use case is.  Up until now we haven't seen many sites trying to do this and so it hasn't been a priority.  What are you trying to do with `self.registration.active`?  Thanks!

Comment 2

[ben last]

Hi Ben

Our use case is that we add query parameters to the service worker URL, that pass (amongst other things) a unique 'client_id' that the worker and page-based JS can use to identify the client to the application server. An ID in the URL is always available (in theory) to the worker and its lifetime matches that of the worker registration. Without this, we have to resort to using postmessage to configure the worker when first registered, which works, but is significantly more complex.

This has become an issue now because we've added code to the activate event handler that requires it to send updated information to the application server, and the client_id is required for that POST.

Comment 3

[ben last]

(I should be a little clearer; we want access to the service worker URL, which is available at self.registration.active.scriptUrl - we don't need the 'active' property for anything except the URL).

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

(In reply to ben last from comment #3)
> (I should be a little clearer; we want access to the service worker URL,
> which is available at self.registration.active.scriptUrl - we don't need the
> 'active' property for anything except the URL).

You can use `self.location` to get at the current worker script executing:

https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/location

Would that work for you?  It would also avoid the possibility of accidentally looking at a ServiceWorker object for a different thread.

Comment 5

[ben last]

That might work... technically we do want the active URL, but this would probably also work in practice, since we don't change the ID in question. Thanks for the suggestion!

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

Per the spec, this should be guaranteed:

  addEventListener('activate', evt => {
    `self.registration.active.scriptURL === self.location.href`
  }