For bug 1549799, I'm working on adding a new about:logins page. Ideally we would use <script type=module> for the various Custom Elements of the UI but when trying to load the scripts I get an error of:

Module source URI is not allowed in this document

To reproduce this, I change AboutRedirector.cpp to load the page over resource:,

resource:///chrome/browser/content/browser/aboutlogins/aboutLogins.html
and update the script elements in aboutLogins.html to use type=module and load their resources using an absolute resoure:// path.

Note: you will need to set signon.management.page.enabled=true in about:config for the page to load

I also removed the meta CSP that is on the page to make sure the error wasn't the fault of the CSP included in the page.

Could it be that <script type=module> is only whitelisted for https:? This about: page is running in a "privileged-about" content process.

Flagging ckerschb and jonco for needinfo as they are the two people I was referred to when asking on IRC.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #0)

Modules are allowed over http. This is happening in a "privileged-about" content process and I suspect that's something to do with it.

Module source URI is not allowed in this document

This message is generated when we get the NS_ERROR_DOM_BAD_URI error code which seems to be a general error for security related failures. Maybe ckerschb knows what security restrictions these privileged-about impose...

Jared, it seems the error reported originates from the generic ReportErrorToConsole function within the ScriptLoader, which has a variety of callsites so I couldn't identify what exactly goes wrong.

If you could add some sort of MOZ_ASSERT(false) here [1] and provide me the stacktrace I am pretty sure we can figure out why the load was blocked. Alternatively, or in addition you could upload a WIP patch which allows me to reproduce the error and I can take a look.

[1] https://searchfox.org/mozilla-central/source/dom/script/ScriptLoader.cpp#3283

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #2)

If you could add some sort of MOZ_ASSERT(false) here [1] and provide me the stacktrace I am pretty sure we can figure out why the load was blocked.

I tried putting a breakpoint there and also MOZ_ASSERT(false) but neither of them could get MSVC to either pause or halt with a stack trace. My build options are the following:

mk_add_options AUTOCLOBBER=1
ac_add_options --disable-av1
ac_add_options --target=x86_64-pc-mingw32
ac_add_options --host=x86_64-pc-mingw32
ac_add_options --enable-debug
ac_add_options --disable-optimize

I do also have the Child Process Debugging Tool (https://marketplace.visualstudio.com/items?itemName=vsdbgplat.MicrosoftChildProcessDebuggingPowerTool) installed so it shouldn't be an issue of the code being run in a different process.

I've attached a WIP patch that reproduces the issue.

Hey :smaug, :gijs,

it seems we would like to use module scripts for the new about:logins page. Currently that doesn't work because module scripts always require CORS and hence the script loading gets blocked in the CORS code here [1] with the following error:

Security Error: Content at about:logins may not load or link to resource:///chrome/browser/content/browser/aboutlogins/components/reflected-fluent-element.js.

Probably we want more about pages to use module scripts in the future so the question is how can we add a carve out to allow that. One possibility would be to simply not require CORS for our own packed module scripts. We could add that carveout within the Scriptloader here [3].

Does that sound like a good path forward, or do you suggest a different strategy using e.g. other protocol flags, different packaging or something there like?

[1] https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsCORSListenerProxy.cpp#912
[2] https://searchfox.org/mozilla-central/source/dom/script/ScriptLoader.cpp#1244
[3] https://searchfox.org/mozilla-central/source/dom/script/ScriptLoader.cpp#1244

Do we need to let only certain pages to be able to load certain modules?
Basically disable cors check for about:[some our internal, privileged page, not accessible from the web] and chrome:* and only if module is from resource: or chrome: ?
Or should it depend on principals?

(In reply to Olli Pettay [:smaug] from comment #6)

Or should it depend on principals?

Note that about:logins has a codebase principal, not the system principal, so we need a solution that works without system principal.

ISTM that we should allow web-unlinkable, content-privileged about: pages to access (non-contentaccessible) chrome: and/or resource: content. It seems right now we don't, but only for JS modules, or something?

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #5)

it seems we would like to use module scripts for the new about:logins page. Currently that doesn't work because module scripts always require CORS and hence the script loading gets blocked in the CORS code here [1]

So, how is this call to checkLoadURIWithPrincipal different to the pretty similar check that a normal script element load does? We must be calling checkLoadURIWithPrincipal somewhere in that case, too - is the principal different? Or do we pass different flags (perhaps ALLOW_CHROME ) ?

That seems like the thing to fix - clearly, we are normally (ie with non-module script loads) able to pass the security checks, so the question is how those security checks are different from the ones employed here - they are (or should be) all checkLoadURI* calls in the end.

Let me provide a quick summary:

• The reason the CheckLoadURIWithPrincipal check within the ContentSecurityManager didn't block the load is because that check is skipped in the case of CORS, see [1]
• Module scripts always require CORS, see [2]
• Within the nsCORSListenerProxy we could add the flag ALLOW_CHROME (see patch) which would allow to pass the CheckLoadURIWithPrincipal check, but that still would result in other CORS erros. Hence, my initial suggestion to bypass CORS entirely for local module scripts. FWIW, the resulting error is:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///home/ckerschb/source/mc/browser/components/aboutlogins/content/components/reflected-fluent-element.js. (Reason: CORS request not http).

My suggesetion:

• Within the ScriptLoader (see patch) we could add a carveout to simply use SEC_ALLOW_CROSS_ORIGIN_DATA_IS_NULL instead of SEC_REQUIRE_CORS_DATA_INHERITS for local module scripts that are triggered by an about: page.
• Everything I mentioned only works if we can use chrome:// URIs, if we have to use resource:// URIs we would have to write additional code within the CheckLoadURIWithPrincipal checks (somewhere here [3]) to allow access.

@Gijs, smaug: What do you think?
@Jaws: Can we use chrome:// URIs to the load the modules (see patch) or was there a specific reason you are using resource:// URIs?

[1] https://searchfox.org/mozilla-central/source/dom/security/nsContentSecurityManager.cpp#1043-1046
[2] https://searchfox.org/mozilla-central/source/dom/script/ScriptLoader.cpp#1242-1243
[3] https://searchfox.org/mozilla-central/source/caps/nsScriptSecurityManager.cpp#981-1013

chrome:// URIs will be OK.

I guess we found a path forward - patches are r+ed, so clearing remaining ni? requests.

https://hg.mozilla.org/mozilla-central/rev/768599bb5965

I'm assuming this can ride the trains. Feel free to reset the 68 flag and request uplift if not.