Update module import hooks to reflect changes in spec
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox143 | --- | fixed |
People
(Reporter: yulia, Assigned: allstars.chh)
References
(Blocks 11 open bugs)
Details
Attachments
(39 files, 16 obsolete 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 | |
|
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 | |
|
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 | |
|
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 |
Recently a refactor to html and ecma262 landed which refactors and simplifies the host hooks. Presentation is here: https://docs.google.com/presentation/d/1RVUE-MENQT8dj2wxvMLMDxg_VoMOwiwNQQged39QIEU/edit#slide=id.g1489ab97056_2_334
write up: https://github.com/nicolo-ribaudo/modules-import-hooks-refactor
Changes to HTML: https://github.com/whatwg/html/pull/8253
Changes to ecma262: https://nicolo-ribaudo.github.io/modules-import-hooks-refactor/
We will need to do this before the larger components of Modules Harmony lands, this includes in particular import reflection and module blocks, as both are already quite mature.
Updated•3 years ago
|
| Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
| Assignee | ||
Comment 2•2 years ago
|
||
According to Additional Fields of Cyclic Module Records.
https://tc39.es/ecma262/#cyclic-module-record
Add a ModuleStatus::New to map to the [[Status]]::New
| Assignee | ||
Comment 3•2 years ago
|
||
See https://tc39.es/ecma262/#graphloadingstate-record
From the specification, the operation uses the PromiseCapability record
to notify when it is resolved or rejected. However, to accommodate our
synchronous loader, mozJSModuleLoader, I have modified the implementation to
use function callbacks instead. This change ensures compatibility with our
existing synchronous loading mechanism.
| Assignee | ||
Comment 4•2 years ago
|
||
Implement [[LoadedModules]] in https://tc39.es/ecma262/#table-cyclic-module-fields
| Assignee | ||
Comment 5•2 years ago
|
||
Replace resolve hook and dynamic import hook with load hook.
| Assignee | ||
Comment 6•2 years ago
|
||
Implement https://tc39.es/ecma262/#sec-GetImportedModule
and update the callers accordingly.
| Assignee | ||
Comment 7•2 years ago
|
||
Originally FinishDynamicModuleImport would resolve the module object,
now we resolve the module object in HostLoadImportedModule, and pass the
module object to FinishDynamicModuleImport.
| Assignee | ||
Comment 8•2 years ago
|
||
Implement InnerModuleLoading in https://tc39.es/ecma262/#sec-InnerModuleLoading
| Assignee | ||
Comment 9•2 years ago
|
||
| Assignee | ||
Comment 10•2 years ago
|
||
Implement Import-Attributes change from https://tc39.es/proposal-import-attributes/#sec-InnerModuleLoading
| Assignee | ||
Comment 11•2 years ago
|
||
| Assignee | ||
Comment 12•2 years ago
|
||
This makes the call to ModuleLoadRequest::InstantiateModuleGraph() from
ModuleLoerBase and ModuleLink() in js shell will call
ModuleLoadRequestedModules() first, and call ModuleLink() in the
resolved callback.
| Assignee | ||
Comment 13•2 years ago
|
||
From the specification, ContinueDynamicImport is done inside the engine.
https://tc39.es/ecma262/#sec-ContinueDynamicImport
However, our implementation for EvaluateModuleInContext() has bytecode
encoding related stuff, so for now I implement the ContinueDynamicImport
in the host layer.
Also, the updated spec has a slightly different error handling behavior when
module.Link() fails. I list them below:
Before HTML PR 8253 [https://github.com/whatwg/html/pull/8253]
fetch the descendants of and link a module script
https://web.archive.org/web/20221130023614/https://html.spec.whatwg.org/#fetch-the-descendants-of-and-link-a-module-script
onFetchDescendantsComplete
Step 3.2. Perform record.Link().
If this throws an exception, set result's error to rethrow to that exception.
HostImportModuleDynamically
https://web.archive.org/web/20221130023614/https://html.spec.whatwg.org/#hostimportmoduledynamically(referencingscriptormodule,-modulerequest,-promisecapability)
Step 6.3 Otherwise, set promise to the result of running a module script given result and true.
run a module script
https://web.archive.org/web/20221130023614/https://html.spec.whatwg.org/#run-a-module-script
Step 5. If script's error to rethrow is not null, then set evaluationPromise to a promise rejected with script's error to rethrow.
After ECMA262 PR 2905 [https://github.com/tc39/ecma262/pull/2905]
ContinueDynamicImport
Step 6.a Let link be Completion(module.Link()).
Step 6.b If link is an abrupt completion, then
Step 6.b.i. Perform ! Call(promiseCapability.[[Reject]], undefined, « link.[[Value]] »).
Step 6.b.ii. Return unused.
In short, the old behavior would catch the exception thrown during
module.Link(), and set the module script's error to rethrow to the
exception. Later in Evaluate(), if the module script's error to rethrow
is not null, reject the evaluation promise with the error to rethrow.
And the new behavior is simply reject the evaluation promise with the
exception thrown during module.Link().
To address this change, I add another
InstantiateDynamicImportModuleGraph() for the different error handling,
and slightly update ModuleLoaderBase::FinishDynamicImport to check if
any exception has been thrown already.
| Assignee | ||
Comment 14•2 years ago
|
||
| Assignee | ||
Comment 15•2 years ago
|
||
The changes in whatwg/html#8253
remove the "Find the first parse error" part. As a result, checking for
parse errors is now done in InstantiateModuleGraph() and
HostLoadImportedModule().
In our implementation, if a ModuleScript has a parse error, it
originally called LoadFinished(), which in turn called
onModuleLoadComplete. However, for WorkerModuleLoader and
WorkletModuleLoader, they called InstantiateModuleGraph(), which then
called HostLoadImportedModule(). This sequence couldn't find the module
script with the parse error, leading to an assertion failure.
To fix this issue, the call to ModuleErrored() has been moved to occur
once the ModuleScript has been inserted into mFetchModules.
| Assignee | ||
Comment 16•2 years ago
|
||
Now the modules will be stored in LoadedModules() of the module object,
replace a already instantiated module with a new one won't trigger the
problem.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 17•1 year ago
|
||
| Assignee | ||
Comment 18•1 year ago
|
||
| Assignee | ||
Comment 19•1 year ago
|
||
| Assignee | ||
Comment 20•1 year ago
|
||
| Assignee | ||
Comment 21•1 year ago
|
||
| Assignee | ||
Comment 22•1 year ago
|
||
| Assignee | ||
Comment 23•1 year ago
|
||
| Assignee | ||
Comment 24•1 year ago
|
||
| Assignee | ||
Comment 25•1 year ago
|
||
| Assignee | ||
Comment 26•1 year ago
|
||
| Assignee | ||
Comment 27•1 year ago
|
||
- UpdateToDependenciesLoaded
- Check parent->IsTopLevel in ChildLoadComplete
| Assignee | ||
Comment 28•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 29•1 year ago
|
||
| Assignee | ||
Comment 30•1 year ago
|
||
| Assignee | ||
Comment 31•1 year ago
|
||
| Assignee | ||
Comment 32•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 33•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 34•1 year ago
|
||
| Assignee | ||
Comment 35•1 year ago
|
||
Updated•1 year ago
|
| Assignee | ||
Comment 36•1 year ago
|
||
Originally each module graph will get different ParseError due to
FindFirstParseError algorithm,
now once a parse error is found, the error will be set to the error to rethrow
on the root module, hence both module graph should get the same error.
| Assignee | ||
Comment 37•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 38•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 39•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 40•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 41•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 42•1 year ago
|
||
| Assignee | ||
Comment 43•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 44•1 year ago
|
||
Comment 45•1 year ago
|
||
I haven't tested this particularly but this should work.
| Assignee | ||
Comment 46•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 47•1 year ago
|
||
| Assignee | ||
Comment 48•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 49•1 year ago
|
||
Hi, arai
I'd like to ask for your suggestion.
Currently I have one xpcshell failure in test_import_global_current.js, it fails in testSyncImportWhileAsyncImportTLA
The try failure is here
Originally (in current m-c), the window.import will fetch the TLA script (es6module_top_level_await.js), then it will be moved to loaded list,
And ScriptLoader will process the loaded request
Now with the patches in this bug here. Part 16 will call LoadRequestedModules, and the module will be loaded in Part 24, notice that the module is loaded when the promise from LoadRequestedModules is resolved. At that time ScriptLoader::OnStreamComplete has returned.
When the module is loaded, it will process the loaded requests asynchronously.
But before the module is processed, the ChromeUtils.importESModule is executed, then the module evaluation from ChromeUtils.importESModule will trigger the assertion
So my question is the test testSyncImportWhileAsyncImportTLA still valid after this bug? As window.import now will take longer to do the actual module evaluation, and what and how should the ChromeUtils.importESModule behave while the importing TLA is still executing?
Thanks
Comment 50•1 year ago
|
||
At least, hitting an assertion failure sounds like there's an issue in the implementation side, not only in the testcase alone.
Then, I think this was actually a pre-existing issue, where the testcase wasn't hitting the problematic path.
We should expect the evaluation promise to be pending for { global: "current" } option, given that the modules it's seeing can be handled by the regular module loader with supports TLA with pending promises.
Thus, we should have another branch around the following code to handle the case where evaluationPromise is pending, and throw an error about "imported module has TLA and it's still getting executed by other module loader", or something says "modules with TLA can be imported with importESModule only after the module is fully evaluated".
We should also assert that the pending case happens only with { global: "current" } option (otherwise the promise shouldn't be pending at that point).
if (!JS::ThrowOnModuleEvaluationFailure(aCx, evaluationPromise,
errorBehaviour)) {
Feel free to disable the testcase for now.
I can look into it later.
| Assignee | ||
Comment 51•1 year ago
|
||
Store LoadContextBase and RootedModule information into LoadedScript/ModuleScript.
| Assignee | ||
Comment 52•1 year ago
|
||
-
Move UpdateReferrerPolicy from ScriptLoadRequest to ModuleLoadRequest,
as this can only happend for a module load. -
Add UpdateReferrerPolicy method to ModuleScript.
Introduces a new UpdateReferrerPolicy method for ModuleScript,
allowing the referrer policy to be updated based on the associated
ModuleLoadRequest.
Updated•1 year ago
|
| Assignee | ||
Comment 53•1 year ago
|
||
When there's a ParseError, the error should be dispatched asynchronously.
However, workers can't handle the micro task, therefore we still call
ModuleErrored synchronously.
WPT test: /html/semantics/scripting-1/the-script-element/module/inline-async-inserted-execorder.html
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 54•1 year ago
|
||
Since the module graph is now traversed within the JS engine itself, the
related data structures in the host layer are no longer necessary.
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 55•1 year ago
|
||
| Assignee | ||
Comment 56•1 year ago
•
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 57•1 year ago
|
||
Comment on attachment 9438862 [details]
Bug 1820594 - Part 33: Update testing/web-platform/tests/html/semantics/scripting-1/the-script-element/module/choice-of-error-1.html.
Revision D229652 was moved to bug 1974658. Setting attachment 9438862 [details] to obsolete.
Comment 58•1 year ago
|
||
Comment on attachment 9439079 [details]
Bug 1820594 - Part 34: Update error-type-1.html
Revision D229651 was moved to bug 1974658. Setting attachment 9439079 [details] to obsolete.
| Assignee | ||
Comment 59•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 60•11 months ago
|
||
In mochitest-browser tests, it's possible for the about:neterror page to
load. This triggers aboutNetError.html, which in turn loads aboutNetError.mjs.
Occasionally, the load promise from
LoadRequestedModules(aboutNetError.mjs) is never resolved because the
PromiseJobRunnable is not executed if the global is in the process of
shutting down.
To avoid this issue, we now use the synchronous version of
LoadRequestedModules when loading chrome resources.
| Assignee | ||
Comment 61•11 months ago
|
||
In mochitest-browser tests, it's possible for the about:neterror page to
load. This triggers aboutNetError.html, which in turn loads
aboutNetError.mjs, eventually importing pkijs.js. The pkijs.js module is
compiled off-thread.
However, when the test framework proceeds to the next test, the
associated document may be detached before the off-thread compilation of
pkijs.js completes. If this happens while TaskController is shutting
down, the compilation task may never finish.
Currently, ScriptLoader only tracks top-level off-thread compilation
requests, not submodules involved in those tasks. To address this, we
now call CancelFetchingModules when ScriptLoader cancels ongoing
requests, ensuring submodule fetches are also properly aborted.
Comment 62•11 months ago
|
||
Comment 63•11 months ago
|
||
Comment 64•11 months ago
|
||
Backed out for causing failures at mochitest.toml.
Backout link: https://hg-edge.mozilla.org/integration/autoland/rev/48134d64e64b943367db3910dac7bebec3c06d28
Failure log: https://treeherder.mozilla.org/logviewer?job_id=518834855&repo=autoland&lineNumber=4976
Comment 66•11 months ago
|
||
Comment 67•11 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/0edfd9c6884d
https://hg.mozilla.org/mozilla-central/rev/b6d75f4f4756
https://hg.mozilla.org/mozilla-central/rev/0ae144aca175
https://hg.mozilla.org/mozilla-central/rev/96ab5aa70275
https://hg.mozilla.org/mozilla-central/rev/a8a18d8f7237
https://hg.mozilla.org/mozilla-central/rev/d07c809e1fd7
https://hg.mozilla.org/mozilla-central/rev/528371e474bb
https://hg.mozilla.org/mozilla-central/rev/1d7c093083ea
https://hg.mozilla.org/mozilla-central/rev/a35abbf73367
https://hg.mozilla.org/mozilla-central/rev/69f593198e24
https://hg.mozilla.org/mozilla-central/rev/bd54f46cdae0
https://hg.mozilla.org/mozilla-central/rev/440c2a2605b3
https://hg.mozilla.org/mozilla-central/rev/03007620a79e
https://hg.mozilla.org/mozilla-central/rev/c5eabc03ec00
https://hg.mozilla.org/mozilla-central/rev/46fc20c776f5
https://hg.mozilla.org/mozilla-central/rev/04606db11850
https://hg.mozilla.org/mozilla-central/rev/8d8d07e5b63c
https://hg.mozilla.org/mozilla-central/rev/e4cb2d8bc88f
https://hg.mozilla.org/mozilla-central/rev/cfff4af812f1
https://hg.mozilla.org/mozilla-central/rev/2b33077bbe0b
https://hg.mozilla.org/mozilla-central/rev/99cfceaf276b
https://hg.mozilla.org/mozilla-central/rev/6d0c7a363043
https://hg.mozilla.org/mozilla-central/rev/6ef880c3361e
https://hg.mozilla.org/mozilla-central/rev/8ce9c39a01cc
https://hg.mozilla.org/mozilla-central/rev/46f3fb297eee
https://hg.mozilla.org/mozilla-central/rev/70e571a4d115
https://hg.mozilla.org/mozilla-central/rev/b21b6ee4cd76
https://hg.mozilla.org/mozilla-central/rev/e505acd05133
https://hg.mozilla.org/mozilla-central/rev/609d8edb3283
https://hg.mozilla.org/mozilla-central/rev/028810114451
https://hg.mozilla.org/mozilla-central/rev/3119dda70eb8
https://hg.mozilla.org/mozilla-central/rev/3f0c9544000e
https://hg.mozilla.org/mozilla-central/rev/f2b1698faa37
https://hg.mozilla.org/mozilla-central/rev/277e23f39103
https://hg.mozilla.org/mozilla-central/rev/bbd0092e97a3
https://hg.mozilla.org/mozilla-central/rev/e2972b033db7
https://hg.mozilla.org/mozilla-central/rev/90cbfb6edeef
Updated•10 months ago
|
Description
•