This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, FetchEvent.default(http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#default-method) in Service Worker spec is invoking fetch with the request's synchronous flag set. But we'd like to change it async so that it can run async as self.fetch() method does. A problem lies in queuing a task for running the "process response" steps. Currently, fetch algorithm step 11 executes "Queue a fetch task on *request* to process response for response." In this setting, the process response steps will run in the service worker client's responsible event loop instead of in the ServiceWorkerGlobalScope's responsible event loop. Could you address this such that the process response steps can run in a client (environment settings object)'s responsible event loop? Something like "To queue a fetch task on request's client client to run an operation, queue a task to run an operation on client's responsible event loop using the networking task source." would be great.
I don't understand. Client points to the service worker, no? Did you read the definition of queue a fetch task?
The request's client referred to within FetchEvent.default() is the service worker client not the service worker as the service worker client is the actual request initiator. So I was trying to see the possibility to set the target of the queue a fetch task explicitly a client rather than a request.
If client is not the service worker, how does comment 0 make sense? It's not entirely clear to me what kind of setup would work best here :-(
(In reply to Anne from comment #3) > If client is not the service worker, how does comment 0 make sense? > Yeah, right. If we wanted this, it should be defined as "To queue a fetch task on environment settings object _client_ to run an operation, queue a task to run an operation on _client_'s responsible event loop using the networking task source." and I would have to run "To queue a fetch task on the service worker(https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#dfn-service-worker-global-scope-service-worker)'s environment settings object to run an operation, do the steps." in e.default() algorithm. > It's not entirely clear to me what kind of setup would work best here :-( If it doesn't make any side effects, overriding the request's client to service worker's environment settings object in e.default() can be an option as well. But I'm a bit worried about this lest it break any forward compatibility with fetch algorithm. What say you?
Say we have a worker A that is controlled by a service worker SW. A invokes fetch() which creates a "fetch" which ends up in SW. If SW then does fetchEvent.default() and that reuses "fetch" from A, how are both parties (A and SW) getting the correct annotated event loop tasks? That seems impossible with the current setup.
So the answer here is to remove default() and mark this WONTFIX, no? See https://github.com/slightlyoff/ServiceWorker/issues/607 about replacing default().
It depends on the conclusion we'll end up. I thought you were opened to find a way to preserve the original (A's) request's setup including request's client (as A's environment settings object) and referrer to keep default(). However, I think e.default() doesn't provide any advantages over fetch(e.request) to authors having considered that Fetch provides Response.finalURL.
Yeah, Referer preservation is lost though perhaps we can make Referer settable and save it. We'll see. I don't think anyone wants default() back at this point though and the proposed model in comment 0 is still broken.