This patch does:
- use our common `Create` pattern also here to move some complexity out of the constructor and improve the error handling.
- give each strong worker ref a unique name for better diagnostics.
- add a `TryShutdown` to the life-cycle worker ref, presumably this may help if the worker dies before any DispatchLoadScript(s) has been called.
Differential Revision: https://phabricator.services.mozilla.com/D192936
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
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
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
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
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
Previously, in the cancellation refactor, we removed knowledge of the list of scripts being loaded on the main thread. As a result of this, we could no longer clear the cache creator on the main thread after iterating over all requests. We can now do that once again, and it simplifies the code.
Differential Revision: https://phabricator.services.mozilla.com/D162220
The ScriptLoaderRunnable used to do double duty as both the runnable used to load a script, and as the data structure to hold on to loading information (what kind of worker, debugger status, etc, if we failed). The second half of these responsibilities remains with the WorkerScriptLoader. WorkerScriptLoader acts as a persistent data structure. ScriptLoaderRunnable is per batch of requests (such as ImportScripts, or a single module load). It works together with the ThreadSafeRequestHandle to load the script.
In the future, when we move to a single threaded implementation, ThreadSafeRequestHandle will likely be merged with WorkerLoadContext, but ScriptLoaderRunnable will stay as a datastructure to represent the batched request, and most of the existing fields (mSyncTarget, the request list) will stay. There is still some massaging to do here, but it gets closer to a final vision of how this should look.
Differential Revision: https://phabricator.services.mozilla.com/D162217
This introduces a new datastructure that wraps the ScriptLoadRequest. Previously, we were using the WorkerLoadContext to access the request, and we made it not cycle collected in order to make it safe across threads. This, of course, broke module behavior, as the cycle needs to be broken in more places, and things get rather complex.
In the spirit of making everyone's life easier, the ThreadSafeRequestHandle exists as a way to move the request to the main thread, operate on it, and then return it to the worker. We no longer need to track and free the WorkerLoadContext. Once the ThreadSafeRequestHandle is returned to the worker, we release the request, and the handle is empty. There is a possibility that this will cause issues, so we should keep an eye on this. Alternatively, we can never release the ScriptLoadRequest and let the ThreadSafeRequestHandle clean it up on destruction.
In the case that we somehow end up releasing on the main thread, we will send a runnable to release the request correctly on the worker.
Differential Revision: https://phabricator.services.mozilla.com/D162213
We will be using the mSyncLoopTarget for module promises, and for returning to the worker thread
when cleaning up for ThreadSafeRequestHandle.
Differential Revision: https://phabricator.services.mozilla.com/D162212
As WorkerLoadContexts now inherit from a non-CC'd loadContextBase, we have two outcomes.
1) we need to break cycles with ScriptLoadRequests manually, so that ScriptLoadRequests can be collected (ScriptLoadRequests must be CC'd).
2) we can now have refptrs to WorkerLoadContexts in the CacheLoadHandler and NetworkLoadHandler classes, and remove any remaining raw pointers to ScriptLoadRequest/WorkerLoadContext. There are cases where the NetworkLoadHandler or CacheLoadHandler might outlive the Worker Loader, so having refpointers here should help us recover in those cases.
Differential Revision: https://phabricator.services.mozilla.com/D160334
This introduces the basic skeleton to make WorkerScriptLoader a ScriptLoaderInterface.
ScriptLoaderInterface defines the methods that are shared between any given ScriptLoader (for
example the DOM script loader, the ComponentScriptLoader) and the ModuleLoader for a particular
component.
This patch also adds documentation to make the role and responsibilities of the
ScriptLoaderInterface clear.
Depends on D147321
Differential Revision: https://phabricator.services.mozilla.com/D147313
This will be used by child modules. This is currently not used, but it will be in modules. I can
move this over to the other bug, if necessary.
Depends on D147325
Differential Revision: https://phabricator.services.mozilla.com/D147321
This brings back the behavior to iterated over all of the load requests to cancel the cache
promise. I tried a couple of different ways of doing this, including deleting the cache, but this
seemed to be the cleanest way.
Depends on D147322
Differential Revision: https://phabricator.services.mozilla.com/D154382
This moves the shutdown operations out of the ScriptExecutorRunnable, and into something that can be
called independent. This does not change the behavior in this case, however it is important for
modules, which will have promises that resolve after the ScriptExecutorRunnable has closed.
Depends on D155231
Differential Revision: https://phabricator.services.mozilla.com/D147322
This enables us to send files to load that are not part of our executing scripts list. This unlocks
the ability to send single module scripts to be loaded without executing them. It also gives
us a way to get the list of files that are to be loaded.
Depends on D147318
Differential Revision: https://phabricator.services.mozilla.com/D155231
