Open Bug 1183625 Opened 6 years ago Updated 3 years ago
support fetch window option
Recently added to the fetch spec: https://github.com/whatwg/fetch/issues/70
Summary: support fetch dialogWindow option → support fetch window option
Note, I think this largely means: 1) Saving the nsIDocument on InternalRequest during FetchEvent dispatch 2) Using the InternalRequest nsIDocument in FetchDriver if its present: https://dxr.mozilla.org/mozilla-central/source/dom/fetch/FetchDriver.cpp?case=true&from=FetchDriver.cpp#248
Jonas, can you explain under what circumstances a worker's principle is not the same as the parent documents? Is it just for data URI workers? https://dxr.mozilla.org/mozilla-central/source/dom/fetch/FetchDriver.cpp?case=true&from=FetchDriver.cpp#244 Can we just combine these two NS_NewChannel() calls into a single NS_NewChannelWithTriggeringPrincipal()? The mDocument would be the loading node while the triggering principal would be the worker's principal.
I don't know what you're trying to accomplish.
(In reply to Jonas Sicking (:sicking) from comment #3) > I don't know what you're trying to accomplish. You wrote this comment very recently in FetchDriver: // For dedicated workers mDocument refers to the parent document of the // worker (why do we do that?). In that case we don't want to use the // document here since that is not the correct principal. I'm asking you to explain it. 1) When can the principal of the worker differ from the parent document? Same origin requirement suggests only data uri worker. Is that correct? 2) Why did you need separate the NS_NewChannel() calls here instead of using the NS_NewChannelWithTriggeringPrincipal()?
See comment 4. I don't think the context of this bug matters. The questions seem pretty straightforward on their own.
> You wrote this comment very recently in FetchDriver: > > // For dedicated workers mDocument refers to the parent document of the > // worker (why do we do that?). In that case we don't want to use the > // document here since that is not the correct principal. Mainly it is confusing that we're setting mDocument to a non-null value in this case since much of the rest of gecko, as well as various web specifications, treat dedicated workers similar to shared workers. I.e. as a separate "thing" with little relation with its parent document other than that it happens to have a MessageChannel to communicate with it. > 1) When can the principal of the worker differ from the parent document? > Same origin requirement suggests only data uri worker. Is that correct? That is currently correct yes. But note that we will use the document passed to NS_NewChannel for more things than just figuring out the origin. > 2) Why did you need separate the NS_NewChannel() calls here instead of using > the NS_NewChannelWithTriggeringPrincipal()? With all NS_NewChannel* function, the "loadingNode" is the node getting access to the result of the load. I.e. the document in which the resulting resource is used. The "triggeringPrincipal" is the principal of the party which triggered the load. This is almost always the same party, but can be different in a few cases. For example when a stylesheet links to an image, the loadingNode is the document which is getting styled. The triggeringPrincipal is the principal of the stylesheet which links to the image. Another example is when the user clicks an <a href="X" target="Y">. There the triggering principal is the principal of the document which contains the <a> tag. The loadingNode in that case is the document which owns the <iframe name="Y"> into which the resulting document is loaded. Document navigation hasn't been fully implemented correctly yet because docshell is a mess. Especially the case of toplevel loads, rather than <iframe>s is still not implemented fully correctly. The intent is that we will use the loadingNode to determine things like origin, CSP policy, referrer, referrer policy, loadgroup, SW-connection, resource-hints, etc. But also for addons to add whatever type of policies they want. For workers we unfortunately don't have an object similar to the loadingNode which we can use to determine the above from. Hopefully we will add such an object at some point which can be passed to NS_NewChannel in place of loadingNode. Until then any worker APIs which create network connections will have to set all of the above manually.
Thanks. I think this bug will be more complex than I implied in comment 1.
I think the infrastructure I'm building to represent Client objects across processes in bug 1293277 will be necessary to implement this.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.