matchAll() runs Request constructor off the main thread

[annevk]

That does not seem possible. You need to run the synchronous stuff at the start of the algorithm, before any parallel steps.

[annevk]

This is also a problem for match() by extension.

[mkruisselbrink]

Is the same also true for pretty much every other method? In particular the ones that return Client instances, maybe also the ones that return ServiceWorker and ServiceWorkerRegistration instances?

[annevk]

Yeah could be. Depends on how things are worded/done.

[annevk]

@jungkees could you perhaps give pointers to the sections in the specification that need review? That would help a lot.

[jungkees]

Ah.. I had to give this pointer: 3d0ee14#commitcomment-14237642.

To sum, it'd be nice if you review whether this change makes sense:

• Before: a queued task (to the client's event loop) captures the window's state and create a WindowClient object there and resolves the returned promise there.
• After: a queued task (to the client's event loop) captures the window's state and only set the corresponding variables defined in the service worker environment. When the task has executed, the steps in the service worker environment create a WindowClient object and resolves using the values set in the variables.

I think WindowClient.focus() is an example that I want you to take a look:

• Before: https://www.w3.org/TR/2015/WD-service-workers-20150625/#client-focus
• After: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#client-focus-method

[annevk]

It seems e.g., matchAll() still invokes the Request constructor from a section that runs in parallel. That is a little odd, because e.g., it means the promise is not guaranteed to reject at the end of the current task, which is what you'd expect.

I would expect methods to do that kind of setup work first, before returning and running some steps in parallel for lookup.

[jakearchibald]

F2F: move the "if request is a string, upgrade to request" steps to before "run in parallel"