Update error handling for dynamic import in various script loaders
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox145 | --- | fixed |
People
(Reporter: allstars.chh, Assigned: allstars.chh)
References
(Blocks 1 open bug)
Details
Attachments
(10 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
This is a follow-up for https://phabricator.services.mozilla.com/D228860
When a dynamic import failed, the script loaders call OnFetchComplete(errorCode) and then CancelDynamicImport()
This is due to the legacy behavior to call FinishDynamicModuleImport.
We could do the error handling in OnFetchComplete, so the error handling code can be shared.
This also requires changing DOM ScriptLoader and Worker ScriptLoader, so I'm moving this change to a new bug.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 1•10 months ago
|
||
| Assignee | ||
Comment 2•10 months ago
|
||
Update the state of the ModuleLoadRequest in OnFetchFailed.
| Assignee | ||
Comment 3•10 months ago
|
||
Reject the dynamic import when the LoadRequestedModules fails.
| Assignee | ||
Comment 4•10 months ago
|
||
To indicate the loading error for a top-level of the module from the dynamic import
is successfully fetched and parsed, but one of its dependencies fails to fetch
or compile.
//Example
import("a.mjs");
// a.mjs
import "./404.mjs";
This patch allows the ModuleLoadRequest::IsErrored() for "a.mjs" returns
true.
| Assignee | ||
Comment 5•10 months ago
|
||
OnFetchComplete will do the error handling and update the state, so we
don't need to call Cancel nor LoadFailed.
| Assignee | ||
Comment 6•10 months ago
|
||
Triggers FinishLoadingImportedModule in Cancel() to prevent memory leak.
| Assignee | ||
Comment 7•10 months ago
|
||
| Assignee | ||
Comment 8•10 months ago
|
||
This test checks that the TypeError from fetching the sub-modules will
be forwarded to the reject handler of the promise of the dynamic import.
| Assignee | ||
Comment 10•9 months ago
|
||
According to the spec, requests created in HostLoadImportedModule have
the isTopLevel flag set to false. This means both static and dynamic
import requests should also have this flag set to false.
HostLoadImportedModule
Step 14. Fetch a single imported module script ...
Fetch a single imported module script
Step 4. Fetch a single module script given url, fetchClient, destination, options, settingsObject, referrer, moduleRequest, false, and onComplete.
The false argument in the second-to-last parameter of 'Fetch a single
module script' corresponds to the top-levl flag.
Fetch a single module script
given a URL url, an environment settings object fetchClient, a
destination destination, a script fetch options options, an environment
settings object settingsObject, a referrer referrer, an optional
ModuleRequest Record moduleRequest, a boolean isTopLevel, an algorithm
onComplete,
The spec was updated in https://github.com/whatwg/html/issues/7996. We’re
updating the implementation to reflect this change.
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Comment 11•9 months ago
|
||
Comment 12•9 months ago
|
||
Comment 13•9 months ago
|
||
Backed out for causing multiple wpt failures
| Assignee | ||
Comment 14•9 months ago
|
||
(In reply to amarc from comment #13)
Backed out for causing multiple wpt failures
I'll fix it in bug 1990764
Comment 15•9 months ago
|
||
Comment 16•9 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/88588284e643
https://hg.mozilla.org/mozilla-central/rev/70130eac1346
https://hg.mozilla.org/mozilla-central/rev/a20ad923b1f8
https://hg.mozilla.org/mozilla-central/rev/52a87b60e974
https://hg.mozilla.org/mozilla-central/rev/c6c863899bf9
https://hg.mozilla.org/mozilla-central/rev/9e2a3327cd0f
https://hg.mozilla.org/mozilla-central/rev/02269004c755
https://hg.mozilla.org/mozilla-central/rev/fe82822fa4a1
https://hg.mozilla.org/mozilla-central/rev/587cbe9d2aaa
Comment 17•9 months ago
|
||
Comment 18•9 months ago
|
||
Backed out as potential cause of javascript engine crashes (bug 1991268)
Comment 19•9 months ago
|
||
Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/e47abb2b8ac7
| Assignee | ||
Comment 20•9 months ago
|
||
I think this is caused by an ongoing dynamic import, but the document is destroyed so the dynamic import request is canceled.
And when the reject handler is called, the mPayload field has been cleared and triggered the crash.
However, I can't reproduce that crash with a test, when the PromiseJobRunnable is about to execute, its global is dying so it doesn't execute at all.
| Assignee | ||
Comment 21•9 months ago
|
||
Comment 22•9 months ago
|
||
Comment 23•9 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/f3f57e90febf
https://hg.mozilla.org/mozilla-central/rev/1fe3698ab5d1
https://hg.mozilla.org/mozilla-central/rev/360f8b5e412b
https://hg.mozilla.org/mozilla-central/rev/e2701bd43ce2
https://hg.mozilla.org/mozilla-central/rev/584beaae1d20
https://hg.mozilla.org/mozilla-central/rev/f06186536887
https://hg.mozilla.org/mozilla-central/rev/f0d873f64979
https://hg.mozilla.org/mozilla-central/rev/a80062ebc58c
https://hg.mozilla.org/mozilla-central/rev/b83b3c1baa19
https://hg.mozilla.org/mozilla-central/rev/6c40df111eaf
Updated•9 months ago
|
Description
•