Bugzilla

With a little DOM workers assistance from asuth, I've discovered that `workerinternals::LoadMainScript(aWorkerPrivate, mScriptURL, WorkerScript, rv);` in `CompileScriptRunnable::WorkerRun` (running on the worker thread) basically hangs between when `new Worker('worker.js')` happens and when `worker.js` actually is executed.  .

The steps performed by `new Worker(url)` begin as follows:

1. [main thread] Create the worker and get/create a thread to run it.
2. [main thread] Send a `CompileScriptRunnable` over to the worker's thread to do all the operations of evaluating the worker script.
3. [worker thread] `CSR` creates and dispatches a `ScriptLoaderRunnable` back to the main thread to do everything involved in downloading the script and executing it (note that this means steps happen both on the main thread *and* on the worker thread).  This dispatch-back uses `AutoSyncLoopHolder` which will generate an event target to dispatch back at the main thread, in blocking fashion from `CSR`'s point of view.
4. [main thread] `ScriptLoaderRunnable` does the `AsyncLoad` (downloading happens on the network thread) and listens for response data using a `LoaderListener`.
5. [main thread] `LoaderListener` waits til all data is downloaded, then hands it off `ScriptLoaderRunnable::OnStreamComplete{,Internal}`.
6. [main thread] `SLR::OSCI` checks for HTTP errors, gloms up CSP header info to apply to script running and such, does a no-op conversion from UTF-8 to UTF-8 (but that has the effect of copying the data to being JSAPI-allocated), creates a `ScriptExecutorRunnable` as metaphorical continuation for "execute this script on the worker thread", then calls `LoadingFinished`.
7. [main thread] `LoadingFinished` calls `runnable->Dispatch()` where `runnable` is the `ScriptExecutorRunnable`, dispatching at the event target derived from the `AutoSyncLoopHolder`'s provided target.

All the above steps run sensibly for this code, and `worker.js` downloads just fine on the main thread, and it all proceeds at an understandable and sensible pace -- no unusual delays here to make a test time out.

(cutting the comment here to get this out of the textbox, at a minimum)

With a little DOM workers assistance from asuth, I've discovered that `workerinternals::LoadMainScript(aWorkerPrivate, mScriptURL, WorkerScript, rv);` in `CompileScriptRunnable::WorkerRun` (running on the worker thread) basically hangs between when `new Worker('worker.js')` happens and when `worker.js` actually is executed.  .

The steps performed by `new Worker(url)` begin as follows:

1. [main thread] Create the worker and get/create a thread to run it.
2. [main thread] Send a `CompileScriptRunnable` over to the worker's thread to do all the operations of evaluating the worker script.
3. [worker thread] `CSR` creates and dispatches a `ScriptLoaderRunnable` back to the main thread to do everything involved in downloading the script and executing it (note that this means steps happen both on the main thread *and* on the worker thread).  This dispatch ends up reporting back to the worker, by means of `CSR` using an `AutoSyncLoopHolder`: a class that creates a nested event loop on the worker thread, to receive the worker-script source text and compile it.  Then this `syncLoop` spins until the event is received.
4. [main thread] `ScriptLoaderRunnable` does the `AsyncLoad` (downloading happens on the network thread) and listens for response data using a `LoaderListener`.
5. [main thread] `LoaderListener` waits til all data is downloaded, then hands it off `ScriptLoaderRunnable::OnStreamComplete{,Internal}`.
6. [main thread] `SLR::OSCI` checks for HTTP errors, gloms up CSP header info to apply to script running and such, does a no-op conversion from UTF-8 to UTF-8 (but that has the effect of copying the data to being JSAPI-allocated), creates a `ScriptExecutorRunnable` as metaphorical continuation for "execute this script on the worker thread", then calls `LoadingFinished`.
7. [main thread] `LoadingFinished` calls `runnable->Dispatch()` where `runnable` is the `ScriptExecutorRunnable`, dispatching at the event target derived from the `AutoSyncLoopHolder`'s provided target.

All the above steps run sensibly for this code, and `worker.js` downloads just fine on the main thread, and it all proceeds at an understandable and sensible pace -- no unusual delays here to make a test time out.

(cutting the comment here to get this out of the textbox, at a minimum)