Open Bug 1706703 Opened 3 years ago Updated 3 years ago

The debugger cannot find the javascript files


(DevTools :: Debugger, defect, P2)



(Not tracked)


(Reporter: sdavidgomez, Unassigned)


(Blocks 1 open bug)



(4 files)

Attached image 1.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

Steps to reproduce:

  1. Go to
  2. Press F12 and go to debugger panel
  3. The debugger cannot find the javascript files
Attached image Chrome.png

Here is what chrome shows

Attached image Firefox.png

Here is firefox

Hi David,

Thanks for reporting!

Blocks: dbg-sources
Severity: -- → S3
Ever confirmed: true
Priority: -- → P3

(In reply to Hubert Boma Manilla (:bomsy) from comment #2)

Created attachment 9217671 [details]

Here is firefox

I don't get the same result when opening DevTools after loading
For me the source panel is empty, and other panels also start breaking. I can't even close DevTools using F12.

However with slightly different STRs:

Then sources are visible. Considering that DevTools are completely broken (can't even be closed), maybe we should bump the priority?

Edit: you will also see sources if your DevTools open on another Panel than the debugger. To fully reproduce the bug, make sure the default panel is the debugger.

In the console I can see:

JavaScript error: resource://devtools/server/actors/network-monitor/network-event-actor.js, line 108: Error: Got a request without a browsingContextID set

It looks like this issue occurs because of a worker target, and goes away if I comment out targetCommand.listenForWorkers = true; (

Not sure the error is too meaningful, I don't get it consistently.

However to get the failure, make sure to toggle the button on the top right of the website UI (otherwise when it's disabled, I think workers are not spawned)

Make sure this toggle is ON.

I think this should be slightly bumped in priority, as the regular DevTools are fully broken on this website.
Can you verify you see the same issue as I do as long as you switch the toggle ON (see comment 7)


Flags: needinfo?(hmanilla)

I do not reproduce any particular error on nightly.
I do reproduce blank debugger on 88 if I open the debugger an the test page already loaded, while this works fine on nightly.
(I ensured that the toggle was ON, it is by default for me)

I do not reproduce any particular error on nightly.

Just reproduced on Nightly FWIW (and after that I get a blank inspector panel and a blank console panel if I try to switch to those)

To be clear, my STRs (latest central, clobber build, clean profile)

(Note: in my tests the bug is only consistent when starting on the Debugger, otherwise, sometimes I get sources, sometimes I still get a functional toolbox...)

Restarting to disable fission on my nightly to double check, which also applied latest updates, I do reproduce blank debugger and inspector and console. Could it be that we regressed recently ? Or this is intermittent and reproduce less on long running sessions?

(In reply to Julian Descottes [:jdescottes] from comment #11)

To be clear, my STRs (latest central, clobber build, clean profile)

I can reproduce with toggle on and fission on
I get a broken blank inspector, blank console and debugger without sources

Flags: needinfo?(hmanilla)
Priority: P3 → P2

It looks like after the toolbox is opened, any panel opened before the debugger will be fine but any opened after will be blank/broken.

I started looking.

This issue is around the workers involved with this checkbox.
It looks like there is 3 workers, involving WASM. But I haven't looked in detail what are these workers.
David, are you the maintainer of this website ? If yes, do you know if there is anything special about them ? Is there really 3 workers ?

From the DevTools side, the toolbox breaks because of a never resolving WatcherActor.watchTargets, which breaks the debugger and all other panels. It only impact the debugger as that's the only panel to watch for workers.
Then, the issue comes from the platform API not working. This isn't the first time we face some not-functional workers. But we may have overlooked that.
I tracked it down to this code:


which only works for one (and sometimes two) out of the three workers.

I tried looking into the C++ codebase behind this, but haven't found anything obviously broken so far.

Sorry, I'm not the maintainer of this website

I reduced the test case to this:
and especially the worker calling Atomics.wait:

Atomics.wait(int32, 0, 0);

This ends up freezing the worker event loop, including the Debugger's one...
We end up stuck here in the platform code:

      NS_ProcessNextEvent(mThread, false);

It is not really clear how to address that.
May be a first stop gap solution would be to ensure that watchTargets always resolve and so we would have a timeout in case any pending worker attach sequence failed?

I imagine that the dbg.initialize will resume and start working as soon as the worker resumes. But it would avoid displaying the worker until it resumes. It is hard to mitigate this as it means that we can do anything in the worker thread until it resumes. And so we can't spawn the WorkerTarget as it runs in the worker thread...

You need to log in before you can comment on or make changes to this bug.