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
I was over eager in introducing the strong pointers to WorkerLoadContext. It turns out that
previously when we were cycle collecting our ScriptLoadRequests, we were also cleaning up everything
related to WorkerLoadContext. Also, in an attempt to fix the cancellation for workers, We
accidentally stopped cleaning up the reference to the cache creator. This patch does the following:
1) cleans up the cache creator reference whenever we finish with a cache load handler. This is done
by calling Fail appropriately. This solves both bug 1798667 (we no longer reach NEW_URI if we fail)
and 1781295 (we no longer leak memory because things were not cleaned up properly).
2) Does no remove the back reference to WorkerLoadContext from the LoadRequest. It turns out that
this is sometimes necessary. There is a chance that we will accidently try to access the
WorkerLoadContext after cancellation. This actually causes problems later on in the module code.
Differential Revision: https://phabricator.services.mozilla.com/D161288
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
