1706703 - The debugger cannot find the javascript files

Status: NEW

(DevTools :: Debugger, defect, P2)

Description

[David]

Attachment: 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 https://lichess.org/analysis
2. Press F12 and go to debugger panel
3. The debugger cannot find the javascript files

Comment 1

[Hubert Boma Manilla (:bomsy)]

Attachment: Chrome.png

Here is what chrome shows

Comment 2

[Hubert Boma Manilla (:bomsy)]

Attachment: Firefox.png

Here is firefox

Comment 3

[Hubert Boma Manilla (:bomsy)]

Hi David,

Thanks for reporting!

Comment 4

[Julian Descottes [:jdescottes]]

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

Created attachment 9217671 [details]
Firefox.png

Here is firefox

I don't get the same result when opening DevTools after loading https://lichess.org/analysis
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:

• open mozilla.org
• open DevTools > Debugger
• navigate to https://lichess.org/analysis

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.

Comment 5

[Julian Descottes [:jdescottes]]

In the console I can see:

JavaScript error: resource://devtools/server/actors/network-monitor/network-event-actor.js, line 108: Error: Got a request https://lichess1.org/assets/_eICX5B/piece-css/cburnett.css 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; (https://searchfox.org/mozilla-central/rev/a09b922e62b1ee5d6a600b8967d98dacf279d997/devtools/client/debugger/src/client/firefox.js#30)

Comment 6

[Julian Descottes [:jdescottes]]

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)

Comment 7

[Julian Descottes [:jdescottes]]

Attachment: toggle_local_evaluation.png

Make sure this toggle is ON.

Comment 8

[Julian Descottes [:jdescottes]]

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)

Thanks!

Comment 9

[Alexandre Poirot [:ochameau]]

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)

Comment 10

[Julian Descottes [:jdescottes]]

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)

Comment 11

[Julian Descottes [:jdescottes]]

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

• open Firefox
• open https://lichess.org/analysis
• make sure the toggle is on
• open DevTools on the Debugger (Cmd + Opt + Z)

(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...)

Comment 12

[Alexandre Poirot [:ochameau]]

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?

Comment 13

[Hubert Boma Manilla (:bomsy)]

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

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

• open Firefox
• open https://lichess.org/analysis
• make sure the toggle is on
• open DevTools on the Debugger (Cmd + Opt + Z)

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

Comment 14

[Hubert Boma Manilla (:bomsy)]

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.

Comment 15

[Alexandre Poirot [:ochameau]]

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.
https://searchfox.org/mozilla-central/source/devtools/client/debugger/src/client/firefox.js#29-35
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.
https://searchfox.org/mozilla-central/source/devtools/shared/DevToolsUtils.js#975-981
I tracked it down to this code:
https://searchfox.org/mozilla-central/source/devtools/server/connectors/worker-connector.js#34-36

      dbg.initialize("resource://devtools/server/startup/worker.js");

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.

Comment 16

[David]

Sorry, I'm not the maintainer of this website

Comment 17

[Alexandre Poirot [:ochameau]]

I reduced the test case to this:
http://techno-barje.fr/fission/wasm/
and especially the worker calling Atomics.wait:
http://techno-barje.fr/fission/wasm/worker.js

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:
https://searchfox.org/mozilla-central/source/dom/workers/WorkerPrivate.cpp#3034

      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...