See bug 1330900 comment 17. We do the nomodule check before we do normal downloading, but we don't skip them during prefetching, afaict.

So we'd need to pass in the nomodule bit via nsHtml5SpeculativeLoad. It looks like people have added (bug 1067345) a ton of members to this in the meantime... Henri, do we want to pass this as a string, or a boolean on the nsHtml5SpeculativeLoad, or a new set of opcodes (we already have script and scriptfromhead; this would end up being orthogonal to that, so give us 4 total script opcodes, which seems a bit fishy).

Oh, and testcase: data:text/html,<script nomodule src="http://example.com"></script> there should be nothing in the network panel of devtools.

(In reply to Boris Zbarsky [:bz] from comment #1) > So we'd need to pass in the nomodule bit via nsHtml5SpeculativeLoad. It > looks like people have added (bug 1067345) a ton of members to this in the > meantime... > > Henri, do we want to pass this as a string, or a boolean on the > nsHtml5SpeculativeLoad, or a new set of opcodes (we already have script and > scriptfromhead; this would end up being orthogonal to that, so give us 4 > total script opcodes, which seems a bit fishy). In order to a) avoid encoding non-string things as string, b) avoid introducing unions unless we have to and c) avoid making the operation objects larger, I suggest adding a new set op opcodes.

Patch to ignore prefetching of nomodule scripts when modules are enabled.

Pushed by jcoppeard@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/6b4ffe42ad3f Don't preload nomodule scripts when modules are enabled r=hsivonen

I have reproduced this bug with Nightly 56.0a1 (2017-07-20) on Ubuntu 12.04 LTS! This bug's fix is verified with latest Beta! Build ID : 20180402175344 User Agent : Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

I have reproduced this bug with Nightly 56.0a1 (2017-07-18) on Windows 10 , 64 Bit ! This bug's fix is Verified with latest Beta ! Build ID 20180404171943 User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 [bugday-20180404]

As per comment 7 and comment 8, I am marking this bug as verified fixed!