1657503 - installing and waiting states are always null on serviceWorker registration update()

Status: UNCONFIRMED

(Core :: DOM: Service Workers, task, P3)

Description

[Samad Aghaei]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36

Steps to reproduce:

After doing some change in our service worker file, perform the following code;

navigator.serviceWorker.ready
.then( registration => registration.update()) // <-- Must resolve the promise object, before updating SW registration
.then( ({installing, waiting, active}) =>
{
installing.postMessage( "skipWaiting" )
//Error, installing is null
//waiting stage is also null, FF will update the SW internally and after more than ONE second, will return the active state object. The same thing is also going on inside SW itself, installing and waiting are always null in updatefound/statechange events. the only stage that these states are not null is on very first register().
})

Actual results:

FireFox invokes update() internally and then resolves the result!
It will ignore the developers code to control the registration/update procedure.
This is an odd behavior and is different than Chromium and WebKit.

Expected results:

It MUST resolve and object with installing and possible waiting state objects and the rest would be up to the developer code, which usually is going through the updatefound/statechange event listeners.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

The spec for update only calls for the job to be scheduled. If there were no jobs on the queue, this will result in a task being queued to run the job being, resulting it being run in parallel. Presumably this means that Chromium and WebKit implement this in such a way that either the parallel job make progress that is able to front-run the update() processing, or (more likely) that they perform some deterministic early serial work on the event loop in question before resolving the update promise (which is allowed).

Can you elaborate on your use-case and, if you've looked at the spec issues related to this, any spec issues you think might relate to this? The next steps for this situation would be to address this at the spec level but it's important to understand the "why" of your request.

Comment 2

[Samad Aghaei]

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #1)

The spec for update only calls for the job to be scheduled. If there were no jobs on the queue, this will result in a task being queued to run the job being, resulting it being run in parallel. Presumably this means that Chromium and WebKit implement this in such a way that either the parallel job make progress that is able to front-run the update() processing, or (more likely) that they perform some deterministic early serial work on the event loop in question before resolving the update promise (which is allowed).

Can you elaborate on your use-case and, if you've looked at the spec issues related to this, any spec issues you think might relate to this? The next steps for this situation would be to address this at the spec level but it's important to understand the "why" of your request.

Andrew,
You are totally right, based on the rule of spec, there is no need to be able to front-run the update processing, as you've mention it and I knew it already before I file it as a bug here.
But, I think if we have can/want-to have control on registration process, we have to have the same control on update process too. Additionally, being cross browser is even more important than following the rule of spec. when Chromium and WebKit implemented it, why don't we have the same functionality in FireFox?
In FireFox, we even can not get the current state changes of the serviceworker from inside of it! meaning "installing" and "waiting" states are ALWAYS null in a serviceworker.
I don't think if fixing it would be a difficult and a major task for the FireFox technical team.
Therefor, I'll take the request of elaborating a specific use case, as an excuse for not will to change.

Thank you.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Samad Aghaei from comment #2)

In FireFox, we even can not get the current state changes of the serviceworker from inside of it! meaning "installing" and "waiting" states are ALWAYS null in a serviceworker.

This is bug 1113522 and that should be fixed in the next couple of releases.

But, I think if we have can/want-to have control on registration process, we have to have the same control on update process too. Additionally, being cross browser is even more important than following the rule of spec. when Chromium and WebKit implemented it, why don't we have the same functionality in FireFox?

I don't think if fixing it would be a difficult and a major task for the FireFox technical team.
Therefor, I'll take the request of elaborating a specific use case, as an excuse for not will to change.

Yes, a lack of consistency between browsers is potentially a web-compatibility problem, which means it's also potentially something that needs to be clarified in the spec and corresponding web platform tests so that any new browser implementations can conform and be compatible.

I'm asking about your use case because when I raise a spec issue about the problem it's possible that without any reasons to standardize WebKit and Chrome's behavior, the consensus might be to match Firefox's behavior because it maps more directly to the spec and the spec's update throttling logic and is likely a small code change for the other browsers. If I understand the use case I can better account for it (and relay it/reference it) in the spec discussion.

If you'd rather not, that's fine and I appreciate you filing the bug as this is something we'll need to address. I'll link the spec issue here when I find an existing issue or file a new one, etc. and you can consider chiming in there. I do see your example involves skipWaiting and that's something to go on.

Comment 4

[Samad Aghaei]

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #3)

(In reply to Samad Aghaei from comment #2)

In FireFox, we even can not get the current state changes of the serviceworker from inside of it! meaning "installing" and "waiting" states are ALWAYS null in a serviceworker.

This is bug 1113522 and that should be fixed in the next couple of releases.

But, I think if we have can/want-to have control on registration process, we have to have the same control on update process too. Additionally, being cross browser is even more important than following the rule of spec. when Chromium and WebKit implemented it, why don't we have the same functionality in FireFox?

I don't think if fixing it would be a difficult and a major task for the FireFox technical team.
Therefor, I'll take the request of elaborating a specific use case, as an excuse for not will to change.

Yes, a lack of consistency between browsers is potentially a web-compatibility problem, which means it's also potentially something that needs to be clarified in the spec and corresponding web platform tests so that any new browser implementations can conform and be compatible.

I'm asking about your use case because when I raise a spec issue about the problem it's possible that without any reasons to standardize WebKit and Chrome's behavior, the consensus might be to match Firefox's behavior because it maps more directly to the spec and the spec's update throttling logic and is likely a small code change for the other browsers. If I understand the use case I can better account for it (and relay it/reference it) in the spec discussion.

If you'd rather not, that's fine and I appreciate you filing the bug as this is something we'll need to address. I'll link the spec issue here when I find an existing issue or file a new one, etc. and you can consider chiming in there. I do see your example involves skipWaiting and that's something to go on.

Got it.
There is ~2 seconds delay on going through register() on every page reloads if there is some byte-change founded in SW file, which still I don't know what the hell is that delay about!. But we don't have such delay on the first ever registration in Chrome, Safari and FireFox.
Also we don't have that delay on update() in page reloads in Chrome and Safari, but not in FireFox!

I'm working on a library highly depends on serviceWorker to cache the resources and to report the app and its status to the server, etc.
The whole Idea is is to have a registered and activated SW, IMMEDIATELY, then we can append some elements as parts of the app to the page and fetch and cache all of the related resources, including fonts and CSS used images.
In such cases, we have to have a most recent updated and activated SW, and we have to have it Immediately, on the both first ever registration and the next page reloads.
The only way to achieve that, is to send a "skipWaiting" message to to the SW on "installing" nor "waiting" state, on register() and update().
A workaround is to use importScripts and check for the module updates manually, but I prefer to have a universal code rather than a polyfilled or vendor specific program.

The good news is that you said the bug 1113522 should be fixed in the next couple of releases. That would be a better way toward ASAP SW!