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
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 was removed as part of an attempt to simplify worker cancellaton. However, this channel cancellation is important, as without it the timing changes when we finish a request. Without it, we continue to load a script, even after a worker has been shut down.
This tracking will help us reimplement cancellation.
Differential Revision: https://phabricator.services.mozilla.com/D162215
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
This patch doesn't change behavior; these APIs were already effectively
infallible, in the sense that it was impossible for them to return anything
other than NS_OK.
The actual API changes here are in xpcom/io/nsIPipe.idl and
xpcom/io/nsPipe3.cpp, and the rest of this patch is just updates to callsites,
removing code that handled failure-flavored return values from these functions.
(All of this removed code was already dead code, effectively.)
Differential Revision: https://phabricator.services.mozilla.com/D161947
