Bugzilla

As I think makes sense, we didn't have any devtools debugger tests that try and create module workers.  (I also didn't see any debugger window tests that jumped out at me as using modules either, but some of the files in the examples directory like react are using module syntax, but there's also transpiled files in there too.)

I created a very basic test derived from [browser_dbg-worker-scopes.js](https://searchfox.org/mozilla-central/rev/983c039377d4e97b381e13f4c3c1680360e6f3e2/devtools/client/debugger/test/mochitest/browser_dbg-worker-scopes.js) and was able to reproduce. the hang under pernosco, trace is at https://pernos.co/debug/qMtUwUHzk6CVz0WYC6SJ7A/index.html (title: "bug 1816933 module hang").  I also ran [browser_dbg-worker-scopes.js](https://searchfox.org/mozilla-central/rev/983c039377d4e97b381e13f4c3c1680360e6f3e2/devtools/client/debugger/test/mochitest/browser_dbg-worker-scopes.js) itself to get a successful example of the debugger working, which gives us https://pernos.co/debug/9hJWJ1YWGULVY6YVlwjnFQ/index.html (title: "bug 1816933 scope success")

At least part of the problem seems to be that [in LoadAllScripts](https://searchfox.org/mozilla-central/rev/983c039377d4e97b381e13f4c3c1680360e6f3e2/dom/workers/ScriptLoader.cpp#238) we are making decisions on how to load the debugger script based on what WorkerPrivate::WorkerType() returns, which is an oversight since the debugger's script type should not vary based on how content is using the worker.  We should probably change [nsIWorkerDebugger::initialize(url)](https://searchfox.org/mozilla-central/rev/983c039377d4e97b381e13f4c3c1680360e6f3e2/dom/workers/nsIWorkerDebugger.idl#48) to take an extra arg.  That said, the top-level load seems to return fine and the calls to LoadSubScript generally look happy, but there does seem to be a point where the [devtools worker bootstrap script](https://searchfox.org/mozilla-central/source/devtools/server/startup/worker.js) goes async as indicated by the CompilerDebuggerScriptRunnable::WorkerRun having returned but th ecalls to LoadSubScript still continue, so if things go off the rails after that, that isn't captured by the return value.  So there's more to investigate still.

As I think makes sense, we didn't have any devtools debugger tests that try and create module workers.  (I also didn't see any debugger window tests that jumped out at me as using modules either, but some of the files in the examples directory like react are using module syntax, but there's also transpiled files in there too.)

I created a very basic test derived from [browser_dbg-worker-scopes.js](https://searchfox.org/mozilla-central/rev/983c039377d4e97b381e13f4c3c1680360e6f3e2/devtools/client/debugger/test/mochitest/browser_dbg-worker-scopes.js) and was able to reproduce the hang under pernosco, trace is at https://pernos.co/debug/qMtUwUHzk6CVz0WYC6SJ7A/index.html (title: "bug 1816933 module hang").  I also ran [browser_dbg-worker-scopes.js](https://searchfox.org/mozilla-central/rev/983c039377d4e97b381e13f4c3c1680360e6f3e2/devtools/client/debugger/test/mochitest/browser_dbg-worker-scopes.js) itself to get a successful example of the debugger working, which gives us https://pernos.co/debug/9hJWJ1YWGULVY6YVlwjnFQ/index.html (title: "bug 1816933 scope success")

At least part of the problem seems to be that [in LoadAllScripts](https://searchfox.org/mozilla-central/rev/983c039377d4e97b381e13f4c3c1680360e6f3e2/dom/workers/ScriptLoader.cpp#238) we are making decisions on how to load the debugger script based on what WorkerPrivate::WorkerType() returns, which is an oversight since the debugger's script type should not vary based on how content is using the worker.  We should probably change [nsIWorkerDebugger::initialize(url)](https://searchfox.org/mozilla-central/rev/983c039377d4e97b381e13f4c3c1680360e6f3e2/dom/workers/nsIWorkerDebugger.idl#48) to take an extra arg.  That said, the top-level load seems to return fine and the calls to LoadSubScript generally look happy, but there does seem to be a point where the [devtools worker bootstrap script](https://searchfox.org/mozilla-central/source/devtools/server/startup/worker.js) goes async as indicated by the CompilerDebuggerScriptRunnable::WorkerRun having returned but the calls to LoadSubScript still continue, so if things go off the rails after that, that isn't captured by the return value.  So there's more to investigate still.