After fixing the main issue for Bug 1676618, I still managed to get a broken debugger when using --jsdebugger with mochitests.

For instance:

• add debugger; after https://searchfox.org/mozilla-central/rev/2c06b16a0c15ae340a0532e319cbf89ef9d21b68/browser/components/search/test/browser/head.js#19
• run ./mach mochitest browser/components/search/test/browser/browser_searchbar_focus_timing.js --jsdebugger
• click on the run all tests window as soon as it appears

If you do the STRs correctly (and are a bit lucky) the debugger will pause, but no source will be visible. The reason behind that is that we are processing a WorkerTargetDescriptor which has no thread attached, and therefore the following call throws:

const threadFront = await targetFront.getFront("thread");

(https://searchfox.org/mozilla-central/rev/2c06b16a0c15ae340a0532e319cbf89ef9d21b68/devtools/shared/resources/legacy-listeners/source.js#40)

The form of the WorkerTargetDescriptor looks like:

{
  actor:"server1.conn0.workerDescriptor218",
  threadActor:null,
  id:"ea89ba08-7b76-064c-a706-cc5e4cc06a7a",
  url:"resource://gre/modules/PageThumbsWorker.js",
  traits:{},
  type:0
}

(in comparison, other worker target descriptors will have a non null thread actor, as well as a console actor)

This can silently fail, if the worker is processed via onTargetAvailable. But if the target is already present when we start watching for the "source" resource, then it will be processed via the following stack:

module.exports@resource://devtools/shared/resources/legacy-listeners/source.js:42:15
_watchResourcesForTarget@resource://devtools/shared/resources/resource-watcher.js:739:41
_startListening@resource://devtools/shared/resources/resource-watcher.js:690:26
watchResources@resource://devtools/shared/resources/resource-watcher.js:149:20

Called by https://searchfox.org/mozilla-central/rev/2c06b16a0c15ae340a0532e319cbf89ef9d21b68/devtools/client/debugger/src/client/firefox.js#48

This is executed in the middle of the debugger startup, so without investigating much further, I guess it makes sense that the debugger will be broken since we failed in the middle of the initialization.

Few things we should consider:

• 1. investigate why this specific worker target descriptor has no thread attached?
• 2. isolate each call to _watchResourcesForTarget to avoid one faulty target breaking everything
• 3. potentially bail in the legacy source listener if getFront("thread") fails (depends on the outcome of investigating item 1)

Also another item to look at: debugger UI initialization should not silently fail. We have an error in the middle of panel.open, we should log a proper error message. Maybe show an error in the DevTools notification bar?

There is an interesting twist to those STRs.

If you start on the webconsole rather than the debugger, the first call to watchResources will be made from the source map service. So in that case, the debugger UI will not fail to start. Maybe it will miss sources but it will be less broken. Based on this I think we should really make the resource-watcher code a bit safer, because it might be called from various places and it will be hard to handle all those potential error paths.

This issue became more visible after introducing the breakpoint resource 1662129. It's legacy listener consistently crashes when attaching to a mochitest.

Let's repurpose.

investigate why this specific worker target descriptor has no thread attached?

So the worker which has no thread is still being attached to. This issue can occur if a TargetList consumer uses getAllTargets, and calls this method while we are in the middle of attaching to a target. We can fix this with something like https://phabricator.services.mozilla.com/D102313 . The idea is simply to avoid making "unattached" targets available from getAllTargets.

isolate each call to _watchResourcesForTarget to avoid one faulty target breaking everything

I think this still makes sense, the downside is that we might let some errors slip. For instance here, even if the try/catch allows --jsdebugger to work, it hides the fact that we are missing a WorkerTarget.

Depends on D103176

https://hg.mozilla.org/mozilla-central/rev/db4a7d1c8e79