1122917 - what load group should a ServiceWorker use while handling a fetch event?

Status: RESOLVED WONTFIX

(Core :: DOM: Workers, defect)

Description

[Ben Kelly [:bkelly, not reviewing]]

Currently we give ServiceWorkers a new load group when they are spun up because they don't have a document associated with them.  The load group values should be based on the attributes on the registering document's load group.

Nikhil raises an interesting question over about this over here:

  https://github.com/slightlyoff/ServiceWorker/issues/592#issuecomment-70340902

What load group should a SW use when handling a fetch event?

The context of that question was canceling requests, but it seems it could have other implications as well.

Do we want the SW intercepting a network request to have the same security settings the originating document had when starting the request?  Or are we guaranteed the document here matches the security info from the registering document?

If a SW intercepts a network request and starts a new, different network request, should that be canceled if the original document navigates away?

Do we want to implement some kind of temporary load group inheritence in SWs while handling fetch events?

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Jonas, as the resident load group and SW expert, what do you think about the questions in comment 0?  I'm leaning towards, yes, we do want to inherit the load group during fetch events.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

Actually, I think temporary inheritence of the load group would be quite hard.  Since handling the fetch event might be async we can have multiple fetch events in flight at once for the same SW.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm not sure which "security settings" you are referring to. If you mean appid/browserflag/private-browsing-mode, then yes, we are guaranteed that they will be the same for the SW and the page it's serving. In fact, we should probably add some assertions about that if it doesn't already exist.

As for what loadgroup to use for network requests.

I would say that for requests initiated from a SW, we should use the SWs loadgroup. I.e. if a SW calls fetch() or XHR or anything else that creates a network request, use the loadgroup of the SW. We should do this independently of if the request happens from withing an onfetch handler or some other event handler or callback.

However I believe that onfetch events have a way to tell the browser "do the default network handling". When that API is used, I think we should use all the "normal" parameters that were used when the page created an nsIChannel. I.e. we should use the loadgroup, referrer, nsILoadInfo security flags, etc as was used when that nsIChannel was created. So in that case we should behave as if the SW didn't exist.

Does that make sense? Is that reasonably doable?

Comment 4

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

Is this a problem anymore?

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

Yea, I don't think this is an issue any more.