Handle Fetch "process response" callback appears to run on wrong event-loop

[gterzian]

Per fetch, queuing the task that does the "process response" goes via https://fetch.spec.whatwg.org/#queue-a-fetch-task

which queues a task on the event-loop of the client of the request.

In here, as part of Handle Fetch, at step 14.7.1, the original request is cloned into preloadRequest, presumably leaving the "client" attribute as it is.

At step 14.7.6, preloadRequest is fetched, and a "process response" for that fetch is defined. In this operation, among other things, preloadResponse is resolved.

Note that preloadResponse is a promise, that is attached to the FetchEvent dispacted in the active worker's scope at step 21.3.11, by way of a task queued on the event-loop of the worker at step 21.3.

So, to me, it appears that preloadResponse is a promise found in the realm of the active worker, not that of the original client of request.

So it appears that the SW spec expects "process response" to happen by way of a task queued on the worker event-loop, which doesn't match the fetch spec, where the task is queued on the event-loop of the client of the request.

I think what the SW spec wants, is for fetch to actually queue parallel steps back to SW, and then from these "process response" parallel steps queue a task on the active worker event-loop, and then from within that task, finally resolve preloadResponse.

This could be done by defining step 14.7.6 along the lines of:

To process response for navigationPreloadResponse, run these substeps:

• Let activeWorker be registration’s active worker.
• Queue a task on activeWorker relevant event-loop(or define the realm exlicitly) to run the following steps:
  • Run the current steps 14.7.6.1.1 to .1.3(resolving or rejecting preloadResponse).

However this requires changing the definition of "process response" in fetch, to use a parallel-queue and/or parallel steps, as discussed at whatwg/fetch#536