Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
Pending->Canceling->Killing (WorkerNeverRan)
Need to clear WorkerPrivate::mPreStartRunnables
Could we call WorkerRunnable::WorkerRun() to release resource? There could be no WorkerGlobalScope...
Pending->Running->Closing->Canceling->Killing(WorkerRan)
Pending->Running->Canceling->Killing(WorkerRan)
When entering “Closing”
1. Keeping receives normal WorkerRunnables
2. Making ParentStatus as Closing
3. Cancel all timeout
4. Don’t clear the main event queue anymore. But we still wait for all SyncLoops be completed.
5. Call WorkerGlobalScope::NoteTerminating() and nsIGlobalObject::DisconnectEventTargetObjects().
6. Switching to “Canceling” by asking parent thread to call WorkerPrivate::Cancel()
When entering “Canceling”
1. Call WorkerGlobalScope::NoteTerminating()
2. Notify StrongWorkerRefs, worker is in “Canceling”, send and complete the corresponding shutdown work right now.
3. Executing all runnables until no normal WorkerRunnables in queue and no WorkerRefs, SyncLoops and children workers
4. Stop receiving normal WorkerRunnables and DisconnectEventTargetObjects of WorkerScope.
4. Entering “Killing”
When entering “Killing”
1. We would not notify WorkerRefs anymore. Logically all WorkerRefs should be released in “Canceling”
2. Executing all remaining ControlRunnables
3. Release corresponding resources of Worker on worker thread.
Depends on D173850
Differential Revision: https://phabricator.services.mozilla.com/D177511
It can fail when canceling the worker (though I couldn't reproduce the
crash locally). Some things were already accounting for it.
Rename some things for consistency.
Differential Revision: https://phabricator.services.mozilla.com/D175126
The default value for the target is Unknown, so all callsites
keep working.
We also add a Target value used for Document precomputation. This
value is enabled in RFP Lite mode, and allows us to precompute
ShouldRFP and cache it for faster computations later. (The later
computations will still check the Target, but won't need to do the
other expensive checks.)
Differential Revision: https://phabricator.services.mozilla.com/D170891
The default value for the target is Unknown, so all callsites
keep working.
We also add a Target value used for Document precomputation. This
value is enabled in RFP Lite mode, and allows us to precompute
ShouldRFP and cache it for faster computations later. (The later
computations will still check the Target, but won't need to do the
other expensive checks.)
Differential Revision: https://phabricator.services.mozilla.com/D170891
These methods only existed because nsIGlobalObject::PrincipalOrNull was not
available off-main-thread, so can now be removed.
Depends on D165198
Differential Revision: https://phabricator.services.mozilla.com/D165199
This centralizes the logic in one place.
In order to do this, we will need to check the principal
off-main thread. (Well, we need to know if it's System
Principal.) Worker and Worklet need special ways to do
this, so create a virtual method for it and let them
override it. This is analogous to the ShouldRFP method
on GlobalObject.
Differential Revision: https://phabricator.services.mozilla.com/D157564
This centralizes the logic in one place.
In order to do this, we will need to check the principal
off-main thread. (Well, we need to know if it's System
Principal.) Worker and Worklet need special ways to do
this, so create a virtual method for it and let them
override it. This is analogous to the ShouldRFP method
on GlobalObject.
Differential Revision: https://phabricator.services.mozilla.com/D157564
This centralizes the logic in one place.
In order to do this, we will need to check the principal
off-main thread. (Well, we need to know if it's System
Principal.) Worker and Worklet need special ways to do
this, so create a virtual method for it and let them
override it. This is analogous to the ShouldRFP method
on GlobalObject.
Differential Revision: https://phabricator.services.mozilla.com/D157564
This adds a virtual method to nsIGlobalObject and implements it for
nsGlobalWindowInner and SandboxPrivate. This means we don't have to put the
logic for dealing with all the different kinds of globals in once place.
Differential Revision: https://phabricator.services.mozilla.com/D141733
We cannot access ClientWebGLContext::mCanvasElement or its associated
nsIPrincipal off the main thread. We use the hash value of the principal
to limit how many WebGL contexts a single domain can create. We can
compute this when the worker is initialized for OffscreenCanvas worker
instances.
Differential Revision: https://phabricator.services.mozilla.com/D128530
OffscreenCanvas can be run on worker threads and is disabled by default.
The existing code trips asserts because we try to use the document,
which is main thread only, directly on the worker thread. This patch
caches the resist fingerprinting status for the worker when it is
created for future reference.
Differential Revision: https://phabricator.services.mozilla.com/D128510