Async module script element without previous script element blocks DOM parsing
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: pjhanzlik, Unassigned)
Details
Attachments
(1 file)
89 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:93.0) Gecko/20100101 Firefox/93.0
Steps to reproduce:
- Open attached "hello empty scripts.html" with Firefox
- I see a paragraph saying "Hello", and an indicator that the page is loading which never goes away
- Open "hello empty scripts.html" with a text editor and uncomment line 2 (which is just an empty script element)
- Open the edited file from step 2 with Firefox
- I see two paragraph elements saying "Hello" and "World" on a fully loaded page
Actual results:
An empty async module script element without a previous sibling script element causes DOM parsing to stop. This leaves the user with a loading indicator and a partially complete DOM. (Potentially no visible DOM if the async module script element is in a document head.)
Expected results:
Pages with a single async module script element (and no other scripts) should not stop DOM parsing.
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Updated•3 years ago
|
Comment 2•3 years ago
|
||
Although there is a workaround consisting in adding an empty script tag before every async module script, this bug can prevent pages from loading at all.
Comment 3•2 years ago
|
||
This bug also recently broke webViews in VSCode (web).
Standalone dataURI STRs:
data:text/html,<body>A<script type=module async></script>B
= Not OK; Expected: "AB". Actual: "A".
Apparently that non-async non-module "fixup" script does not have to be direct previous sibling, it just have to precede the async module in the DOM tree:
data:text/html,<head><script></script></head><body>A<script type=module async></script>B
= OK.
Description
•