1183625 - support fetch window option

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Ben Kelly [:bkelly, not reviewing]]

Recently added to the fetch spec:

  https://github.com/whatwg/fetch/issues/70

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

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

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 3

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

I don't know what you're trying to accomplish.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

(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()?

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

See comment 4.  I don't think the context of this bug matters.  The questions seem pretty straightforward on their own.

Comment 6

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

> 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.

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

Thanks.  I think this bug will be more complex than I implied in comment 1.

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

I think the infrastructure I'm building to represent Client objects across processes in bug 1293277 will be necessary to implement this.