Strict MIME type checks breaks dynamic import of JSON modules in workers
Categories
(Core :: DOM: Workers, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr128 | --- | unaffected |
| firefox-esr140 | --- | wontfix |
| firefox140 | --- | wontfix |
| firefox141 | --- | wontfix |
| firefox142 | --- | wontfix |
| firefox143 | --- | fixed |
People
(Reporter: jon4t4n, Assigned: jon4t4n)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
Since bug 1858078 JSON module (i.e. with {type: "json"}) loads have their own nsContentPolicyType(s), and bug 1966620 will start enforcing strict MIME type checking for JSON loads. In WorkerScriptLoader::GetContentPolicyType, we currently always return nsIContentPolicy::TYPE_INTERNAL_MODULE for dynamic imports, so JSON modules will fail to load. We want to change this to return nsIContentPolicy::TYPE_JSON, similar to what we do in the DOM script loader.
Comment 1•6 months ago
|
||
Set release status flags based on info from the regressing bug 1858078
| Assignee | ||
Comment 2•6 months ago
|
||
Since bug 1858078, JSON modules (using {type: "json"}) have dedicated
nsIContentPolicy values, and bug 1966620 will enforce strict MIME type
checking.
Currently, WorkerScriptLoader::GetContentPolicyType always returns
nsIContentPolicy::TYPE_INTERNAL_MODULE for dynamic imports, which
causes JSON modules to fail loading when strict MIME checking is
applied.
This patch changes GetContentPolicyType to return
nsIContentPolicy::TYPE_JSON for JSON modules, matching the behavior of
the DOM script loader and fixing dynamic imports of JSON modules in
worker contexts.
Updated•6 months ago
|
Updated•6 months ago
|
Updated•5 months ago
|
Comment 3•5 months ago
|
||
Set release status flags based on info from the regressing bug 1858078
Updated•5 months ago
|
| Assignee | ||
Comment 5•5 months ago
|
||
(In reply to Tom Schuster (MoCo) from comment #4)
Do you need help getting this landed?
Been OOO for a week, but now when I tried to land the stack, it looks odd in lando. The repository of https://phabricator.services.mozilla.com/D257112 is beta and not autoland for some reason. Do you know if I can just edit the revision in Phabricator and select the autoland repository?
Comment 6•5 months ago
|
||
I am not sure, I would just try it? You should not be able to push to beta accidentally if you are worried about that.
Comment 7•5 months ago
|
||
It's bug 1963406. You can fix the target repository by going to "Edit Revision" and changing it back to autoland. Double check the diff that phabricator shows. It will have changed the diff back to the version that was commited and backed out on July 16. So if you have made changes since then, you will need to use moz-phab again to get your most recent local changes back into phabricator.
Comment 9•5 months ago
|
||
| bugherder | ||
Comment 10•5 months ago
|
||
The patch landed in nightly and beta is affected.
:jon4t4n, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
- If no, please set
status-firefox142towontfix.
For more information, please visit BugBot documentation.
Updated•5 months ago
|
Updated•5 months ago
|
Updated•4 months ago
|
Description
•