Bug in ModuleBuilderInitArray causes asserts from the previous import to be applied to the current import
Categories
(Core :: JavaScript Engine, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox-esr102 | --- | disabled |
firefox102 | --- | disabled |
firefox103 | --- | disabled |
firefox104 | --- | fixed |
People
(Reporter: jon4t4n, Assigned: jon4t4n)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(1 file)
The assertionArray
variable is declared outside the loop (See ModuleBuilderInitArray), but we never reset the value inside the loop. Hence, we reuse the previous value if the current entry has no assertions.
This bug can be observed by having two imports. One import with an assert and the other import without an assert.
Working example:
import a from 'foo.js';
import b from 'bar.json' assert { type: 'json' };
If we now re-order the imports, the bug will appear:
import b from 'bar.json' assert { type: 'json' };
import a from 'foo.js';
Assignee | ||
Comment 1•2 years ago
|
||
We need to reset the assertionArray
variable if the current entry has no
assertions. Otherwise, the ModuleRequestObject will be created with the
assertions of the previous import.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 2•2 years ago
|
||
Set release status flags based on info from the regressing bug 1736060
Updated•2 years ago
|
Updated•2 years ago
|
Pushed by mgaudet@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c4bfb83234c2 Reset assertionArray inside the loop of ModuleBuilderInitArray r=mgaudet
Comment 4•2 years ago
|
||
bugherder |
Comment 5•2 years ago
|
||
Is there a user-facing impact for this bug which would warrant ESR102 uplift consideration? Please nominate if so.
Comment 6•2 years ago
|
||
No, import assertions are not, and will not be, enabled on 102. So this need not be uplifted.
Updated•2 years ago
|
Description
•