In the test file, worker_bug1824498.mjs, it imports two module scripts,
"foo" and "bar", both are invalid specifiers.
The ModuleLoadRequest of "foo" will be canceled, which in turn will:
1. Cancel all imports of the parent ModuleLoadRequest (worker_bug1824498.mjs)
2. Cancel the ModuleLoadRequest of "bar".
After the step 1, WorkerModuleLoader::OnModuleLoadComplete will be
called, and will shutdown the script loader.
The shutdown causes two problems:
1. When step 2 is executed, it will reject the mReady promise in
ModuleLoadRequest, however when the MozPromise is dispatched, its event
target has been shutdown so an assertion failure is triggered.
2. Also when the ScriptLoaderRunnable of "bar" is received, it also
triggers the assertion failure of the valid SyncLoopEventTarget.
To fix the problem, we delay the shutdown until there's no ongoing module
requests.
Differential Revision: https://phabricator.services.mozilla.com/D175476
This prevents loading the debugger script the same way the worker is loaded.
So prevent loading it as ES Module when the worker is using ES Module.
Differential Revision: https://phabricator.services.mozilla.com/D173257
I don't think there's ever a way these should differ.
Got some include hell from removing ReferrerInfo.h from Document.h but
hopefully should be straight-forward to review.
Depends on D173154
Differential Revision: https://phabricator.services.mozilla.com/D173155
As mentioned in the previous patch, this patch introduces tracking and shutdown of scriptloaders in
the case that we have multiple scriptloaders involved in module loading.
Differential Revision: https://phabricator.services.mozilla.com/D171686
Earlier, we introduced GetBaseURI to the module loader. This allows us to get the BaseURI for a
dynamic import even after the importing script/module's ScriptLoader has been cleaned up. However,
we now need to be able to handle the case where we need to run the dynamic import and load it. In
order to do this, we need to create a scriptloader configured for dynamic import. The most important
difference between this scriptloader and the one that is normally used for script loading in workers
is that we *do not have a syncLoopTarget* to which we return. There are a couple of reasons for
this:
* Dynamic import (and modules in general) relies on the event loop to resolve. If we create a
syncLoop here, we will end up pausing execution, and this breaks the StartModuleLoad algorithm. We
will never complete and the result will be that we are in the wrong state when we return here.
* We do not have perfect knowledge of the future, so we cannot keep the existing script loader alive
in the case that it might be used for loading in the future.
* We cannot migrate the ModuleLoader to not use sync loading without significantly changing other
aspects of how loading scripts on workers works. This becomes particularily evident with error
handling
(https://searchfox.org/mozilla-central/rev/00ea1649b59d5f427979e2d6ba42be96f62d6e82/dom/workers/WorkerPrivate.cpp#383-444),
and in addition, for reasons I wasn't able to discern, using the CurrentEventTarget results in hard
to identify errors. When there is time to investigate this fully, the ModuleLoader may move away
from using a syncLoop itself.
For now, all main-script loads (whether they are modules or classic scripts) will use the sync loop,
and all dynamic imports will create a new script loader for their needs that is not using the sync
loop. The book keeping for this is in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D171685
This patch introduces modules workers to shared workers. This includes the necessary chagnes to pass
the "type: module" to the shared worker. Beyond that, this patch relies on the work landed in
dedicated workers.
Depends on D162743
Differential Revision: https://phabricator.services.mozilla.com/D156103
This patch introduces modules workers to shared workers. This includes the necessary chagnes to pass
the "type: module" to the shared worker. Beyond that, this patch relies on the work landed in
dedicated workers.
Depends on D162743
Differential Revision: https://phabricator.services.mozilla.com/D156103
This patch introduces modules workers to shared workers. This includes the necessary chagnes to pass
the "type: module" to the shared worker. Beyond that, this patch relies on the work landed in
dedicated workers.
Depends on D162743
Differential Revision: https://phabricator.services.mozilla.com/D156103
This is a slightly annoying thing that can happen. When we abruptly cancel (such as an infinitely
running script being forcibly terminated) we will be in a state where the EvaluateModule call will
finish _after_ the loader is destroyed. So, instead we track if there has been a forcible
cancelation, and exit early.
Depends on D155690
Differential Revision: https://phabricator.services.mozilla.com/D155568
In our implementation, we do not have "client" as a referrer, so we resolve the URI directly as part
of ScriptLoadRequest creation.
Depends on D147327
Differential Revision: https://phabricator.services.mozilla.com/D155567
ImportScripts should be disallowed for module works, which are initialized in the following way:
`new Worker("url", { module:true})`. We set the WorkerType for workers accordingly, and can use that
to detect if import scripts are being incorrectly used.
Depends on D147326
Differential Revision: https://phabricator.services.mozilla.com/D147329
This implements a method to initialize the moduleLoader for workers. This will initialize only once, for all worker types (module and classic).
Depends on D147324
Differential Revision: https://phabricator.services.mozilla.com/D147326
This is a slightly annoying thing that can happen. When we abruptly cancel (such as an infinitely
running script being forcibly terminated) we will be in a state where the EvaluateModule call will
finish _after_ the loader is destroyed. So, instead we track if there has been a forcible
cancelation, and exit early.
Depends on D155690
Differential Revision: https://phabricator.services.mozilla.com/D155568
In our implementation, we do not have "client" as a referrer, so we resolve the URI directly as part
of ScriptLoadRequest creation.
Depends on D147327
Differential Revision: https://phabricator.services.mozilla.com/D155567
ImportScripts should be disallowed for module works, which are initialized in the following way:
`new Worker("url", { module:true})`. We set the WorkerType for workers accordingly, and can use that
to detect if import scripts are being incorrectly used.
Depends on D147326
Differential Revision: https://phabricator.services.mozilla.com/D147329
This implements a method to initialize the moduleLoader for workers. This will initialize only once, for all worker types (module and classic).
Depends on D147324
Differential Revision: https://phabricator.services.mozilla.com/D147326
This is a slightly annoying thing that can happen. When we abruptly cancel (such as an infinitely
running script being forcibly terminated) we will be in a state where the EvaluateModule call will
finish _after_ the loader is destroyed. So, instead we track if there has been a forcible
cancelation, and exit early.
Depends on D155690
Differential Revision: https://phabricator.services.mozilla.com/D155568
In our implementation, we do not have "client" as a referrer, so we resolve the URI directly as part
of ScriptLoadRequest creation.
Depends on D147327
Differential Revision: https://phabricator.services.mozilla.com/D155567
ImportScripts should be disallowed for module works, which are initialized in the following way:
`new Worker("url", { module:true})`. We set the WorkerType for workers accordingly, and can use that
to detect if import scripts are being incorrectly used.
Depends on D147326
Differential Revision: https://phabricator.services.mozilla.com/D147329
This implements a method to initialize the moduleLoader for workers. This will initialize only once, for all worker types (module and classic).
Depends on D147324
Differential Revision: https://phabricator.services.mozilla.com/D147326
