Kristofer Baxter Reporter
	Description • 7 years ago

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36

Steps to reproduce:

1. Ensure 'dom.moduleScripts.enabled' is set to false via about:config.
2. Create a sample page containing two script tags in the head of the document, one <script type="module"> and the other <script nomodule>.
3. Load the document.
4. Change 'dom.moduleScripts.enabled' to true via about:config.
5. Reload the document.

Github repo is here to reproduce: https://github.com/kristoferbaxter/preset-env-modules


Actual results:

Both the module and nomodule scripts were requested from the web server on both document loads.

On the first document load only the nomodule script was leveraged.
On the second document load only the type="module" script was leveraged.


Expected results:

Only a single script should have been requested and leveraged.

On the first document load, only the nomodule script.
On the second document load, only the type="module" script.

	Till Schneidereit [:till]
	Comment 4 • 7 years ago

Thank you for reporting this. It looks like we fixed the version with modules enabled in bug 1382020, but not the one with modules disabled: we still load the module script in addition to the nomodule one in that case.

	Kristofer Baxter Reporter
	Comment 5 • 7 years ago

Great news to see 1382020 was fixed! Thank you for taking a look.

	Jon Coppeard (:jonco) (PTO until 14th September)
	Comment 6 • 7 years ago

(In reply to Kristofer Baxter from comment #0)
This flag was to allow development of modules without affecting users.  The idea was that when it is false the browser functions as if it doesn't support or recognise modules at all.  Hence it doesn't attach any interpretation to 'type="module"' or 'nomodule' and preloads/loads the scripts anyway.  It was not the intention to support modules but provide a way of not loading them.

This is not obvious and perhaps the flag is badly named.  I'm not sure whether it's worth fixing this though.

	Jon Coppeard (:jonco) (PTO until 14th September)
	Comment 7 • 7 years ago

I'm closing as WONTFIX.  Please reopen if you feel strongly about it.

	Michał Gołębiowski-Owczarek [:mgol]
	Comment 8 • 7 years ago

(In reply to Jon Coppeard (:jonco) from comment #6)
> (In reply to Kristofer Baxter from comment #0)
> This flag was to allow development of modules without affecting users.  The
> idea was that when it is false the browser functions as if it doesn't
> support or recognise modules at all.  Hence it doesn't attach any
> interpretation to 'type="module"' or 'nomodule' and preloads/loads the
> scripts anyway.  It was not the intention to support modules but provide a
> way of not loading them.
> 
> This is not obvious and perhaps the flag is badly named.  I'm not sure
> whether it's worth fixing this though.

The real issue is that the default configuration in production version of Firefox, i.e. without modules support still downloads the scripts with `type="module"`. This means a degraded experience for Firefox users (they'll download double the JS they should) so IMO it should still be fixed. Firefox with modules support disabled should treat scripts with `type="module"` as `type="fake-type"` and not download the file.

I think this should still be fixed unless you think you'll enable modules soon enough that it's not worth fixing. It is a real issue, though.

BTW, Re comment #4, blocking bug 1240072 doesn't seem adequate as it's not a bug in Firefox that has modules support enabled but in the current one that doesn't.

Can we reopen this?

	Michał Gołębiowski-Owczarek [:mgol]
	Comment 9 • 7 years ago

I've tested it further and it seems to be a more general problem, not really related to modules.

Chrome & Safari, even in versions from before they enabled modules support, only download scripts if they don't have the type attribute or have the correct JS one. If they don't recognize it, they ignore it. This applies to `type="foo-bar"` in all Chrome/Safari versions but also to `type="module"` in older ones.

Firefox & Edge download all scripts and just skips executing the unknown ones (this applies even to Edge 16 that supports module scripts).

To test, open http://output.jsbin.com/dupewun, load DevTools' Network tab (in any browser) and reload the page. Then filter the requests by "example.com" as all three scripts link to fake content there.

I'll reopen the issue for now then; you may close it if you don't think this is important but for me it does seem to be an issue. Content not meant to be used shouldn't be downloaded.

	Boris Zbarsky [:bzbarsky]
	Comment 10 • 7 years ago

> The real issue is that the default configuration in production version of Firefox,
> i.e. without modules support still downloads the scripts with `type="module"`.

Yes, this is the expected behavior for a browser that has no idea that modules exist at all.

> This means a degraded experience for Firefox users

I agree that this is a problem that we should think about fixing.  Ideally by shipping modules, but if not, maybe we need to think about some sort of hack here; see below.

> Firefox with modules support disabled should treat scripts with `type="module"`
> as `type="fake-type"`

It does.

> and not download the file.

The whole point is that <script type="fake-type"> _is_ downloaded in Firefox.  You can trivially see this behavior in the networking section in the web console.  This is commonly used as a "prime the cache" mechanism by sites, last I checked.

So what you are asking is that type="module" _not_ be treated as type="fake-type" even when the module pref is disabled....

	Boris Zbarsky [:bzbarsky]
	Comment 11 • 7 years ago

(Comment 10 mid-aired with comment 9, which rediscovers the actual behavior here.)

It's a bit surprising to me that Chrome and Safari don't have the same behavior around unknown types.  They used to, I thought...

	Boris Zbarsky [:bzbarsky]
	Comment 12 • 7 years ago

It's possible that they changed behavior at some point when the HTML spec actually started defining the behavior here.  See also bug 838521.

	Jon Coppeard (:jonco) (PTO until 14th September)
	Comment 13 • 7 years ago

(In reply to Michał Gołębiowski-Owczarek [:mgol] from comment #8)
> I think this should still be fixed unless you think you'll enable modules
> soon enough that it's not worth fixing.

I intend to enable modules today (or when the trees open again) in bug 1438139, so that should fix this issue as far as modules go.

	Michał Gołębiowski-Owczarek [:mgol]
	Comment 14 • 7 years ago

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #10)
> So what you are asking is that type="module" _not_ be treated as
> type="fake-type" even when the module pref is disabled....

Actually, what I'd like to see is that neither of them is downloaded. That's what Chrome & Safari do.

From your last comment I see it's already covered by bug 838521, though, so this one can be closed. Sorry for the fuss.