The issue seems to be out of TE-scope as it is related to content scripts and CORS. Hence, adding label TE-NeedsTriageHelp for further investigation from dev team.

Thanks...!!

Removing Internals>Network as CORS is done outside of the net stack proper.

+rdevlin.cronin@ and tyoshino@: Can the two of you work out what the interaction between in-page content scripts and CORS requests ought to look like? Thanks!

Origins that match the pattern specified by the "permissions" section of manifest.json are treated as the same-origin.

The Origin header will be omitted given that the request's method is either GET or POST.

See the step 10 of this algorithm. The CORS flag is not set for this case.
https://fetch.spec.whatwg.org/#concept-http-network-or-cache-fetch

For future reference, see SecurityPolicy::IsAccessWhiteListed() call in SecurityOrigin::CanRequest(). The pattern in the permissions section is propagated to SecurityPolicy to make it return true.

If its supposed to treated as same origin, then all headers should be visible, correct? I have not found this to be the case - I can only access other headers if Access-Control-Expose-Headers is sent I the response.

Oh, ok. Sorry, I missed the last half of your initial comment.

They, the logic to decide whether to expose the response headers and the logic to decide whether to run CORS or not, are using the same code to determine same-origin-ness. So, it's expected that you'll see the headers. Let me investigate.

Thanks for the report. It's a bug.

The logic XMLHttpRequest has honors the white listing but fetch() doesn't. The extension is using fetch().

FetchManager::Loader::DidReceiveResponse() sets response tainting based on the page's origin and the target resource's origin, but it's using IsSameSchemeHostPort() method instead of CanRequestNoSuborigin() which calls IsAccessWhiteListed().

Devlin, are you fine with making fetch() aligned with XMLHttpRequest from extensions team's perspective?

This issue is not limited to content scripts, extension pages at the chrome-extension: scheme are also affected.

Here is another concrete example that demonstrates the issue: https://github.com/mozilla/pdf.js/issues/9446#issuecomment-363409605

@#11 From the extensions perspective, it should be fine to align "fetch" with "XMLHttpRequest". There are ugly work-arounds to get the header otherwise (e.g. ditching fetch and using XMLHttpRequest, or using the webRequest API to read headers), so constraining "fetch" makes no sense.

Nasko + Charlie, is this going to be fixed by the work on  issue 796480 ?

Just based on the report being about version 61.0.3163.100, I wouldn't think so.   Issue 796480  fixes an issue that was introduced by r522016 in 63.0.3239.108, specific to SameSite cookies.  That said, there were some changes to Origin plumbing in r522016, so it's possible it could affect behavior here.  (I haven't tested this particular bug.)

> The Origin header will be omitted given that the request's method is either GET or POST.

Currently, even if you set {mode: 'cors'} (which I interpret as the cors flag which should also trigger setting an Origin header mentioned in the spec, correct me if I'm wrong), it won't include an Origin header either (Chrome 68). So, I still think the Origin behvior is broken. How would I accomplish a GET request with fetch where the Origin header is set?

Let me know if I should open a new issue for this.