Should add a “script type” check in the register algorithm.

[d0iasm]

In the current spec, we finish a new register job when it equals newestWorker. Spec says (Register 5. 3. ):

3. If newestWorker is not null, job’s script url equals newestWorker’s script url, and job’s update via cache mode's value equals registration’s update via cache mode, then:
   1. Invoke Resolve Job Promise with job and registration.
   2. Invoke Finish Job with job and abort these steps.

However, a new register job should be alive when its script url/update via cache equal newestWorker’s ones but its script type does not equal newestWorker’s one. I think script type should also be checked.

[mfalken]

Yes, this looks like just an oversight. It should be easy to patch the spec. Did you have WPT ready to test this?

[d0iasm]

Did you have WPT ready to test this?

Yes. I just added a new test for updating the registration with different script type.
web-platform-tests/wpt#13692

[d0iasm]

Just concern:
If in the case that

1. A user register SW as classic script type.
2. A user update it to module script type and the main script using module specific syntax(like “import ‘sw2.js’;”).
3. Only run Update Job without running Register Job (It would happen if a user accesses a page in scope but not a top-level page).
4. Fail update because of an evaluation error.

Update Job keeps to fail until a user accesses a top-level page having navigator.serviceWorker.register(‘sw2.js’, {type: ‘module’});

Is this behavior intentional?

[mfalken]

Is this behavior intentional?

If I'm understanding the concern, it's that the server has changed the script from a classic script to a module script and so Soft Update would fail because the registration is still set to classic script.

I think that's fine. To change the script type you should probably change the script URL to avoid this problem. I'm assuming there is no plan to do something like add info to HTTP response headers to let the browser know whether it's a module or classic script? @domenic

[annevk]

There's whatwg/html#3205, but that's really about confirming the request and hasn't gotten support (though maybe it could be used for this as well).

[mfalken]

Addressed in #1411.