In bug 1769913, we remove the WorkerThreadRunnable's raw pointer to the corresponding WorkerPrivate and expect the corresponding WorkerPrivate to be obtained by GetCurrentThreadWorkerPrivate() when WorkerThreadRunnable::Run executing.
In general, the assumption is correct. However, it could be violated in the following two situations.
1. WorkerJSContext initialization fails.
2. WorkerThreadRunnable dispatching after CycleCollector shutdown.
In both cases, there is no corresponding WorkerJSContext to get its mWorkerPrivate by GetCurrentThreadWorkerPrivate(), which causes WorkerThreadRunnable to have no WorkerPrivate for executing.
For case 1, the WorkerThreadRunnables are all from WorkerPrivate::mPreStartRunnables. These runnables need a WorkerPrivate to execute WorkerRun(). To cleanup the resources through WorkerRun() if Worker initialization fails or shutdown before DoRunLoop() starts, WorkerThreadRunnable saves a CheckedUnsafePtr<WorkerPrivate> when the runnable is dispacthed to WorkerPrivate::mPreStartRunnables.
For case 2, the solution could be much easier since the WorkerThreadRunnable is not really a WorkerThreadRunnable. Because the Worker is in the "Dead" state, the WorkerThreadRunnable could not be dispatched normally, which means by WorkerThreadRunnable::Dispatch(WorkerPrivate). So it must be from NS_DispatchToCurrentThread(), WorkerThread::Dispatch(), or other ways which treat WorkerThread as nsIThread/nsISerialEventTarget, where the runnable is wrapped as a WorkerThreadRunnable and call nsThread::Dispatch() directly. In this case, the runnable does not need to be WorkerThreadRunnable, so we should be able to call the runnable's Run() directly.
Differential Revision: https://phabricator.services.mozilla.com/D208259
b68bc791d0