1837480 - Debugger automatically continues execution when moving mouse and hovering over source code

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P2)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I've seen this happening quite often already that the debugger doesn't wait until the next or continue button is clicked but automatically continues the execution sporadically. So far I have seen that when debugging code from the Remote Protocol, here specifically in the content process.

A recording of this problem can be found at:
https://www.dropbox.com/s/73hbpo1xkmwbtpk/debugger.mov?dl=0

And here the related browser log when running a browser chrome test:

 0:06.76 GECKO(30963) JavaScript warning: resource://devtools/server/actors/utils/event-loop.js, line 82: debuggee 'resource:///actors/AboutReaderChild.sys.mjs:205' would run
 0:06.76 INFO Console message: [JavaScript Warning: "debuggee 'resource:///actors/AboutReaderChild.sys.mjs:205' would run" {file: "resource://devtools/server/actors/utils/event-loop.js" line: 82}]
 0:31.90 PASS Got expected amount of internalIds in serializationInternalMap - 0 == 0 -
 0:31.90 PASS Got expected structure - {"type":"window"} deepEqual {"type":"window"} -
 0:31.90 INFO Checking 'node' with none ownershipType
 0:32.04 GECKO(30963) JavaScript warning: resource://devtools/server/actors/object.js, line 64: debuggee 'resource://gre/modules/ContentDOMReference.sys.mjs:1' would run
 0:32.04 INFO Console message: [JavaScript Warning: "debuggee 'resource://gre/modules/ContentDOMReference.sys.mjs:1' would run" {file: "resource://devtools/server/actors/object.js" line: 64}]
 0:33.12 GECKO(30963) console.error: (new Error("Polling for changes failed: Unexpected content-type \"text/plain;charset=US-ASCII\".", "resource://services-settings/remote-settings.sys.mjs", 324))
 0:33.51 GECKO(30963) 30965> console.error: (new Error("Polling for changes failed: Unexpected content-type \"text/plain;charset=US-ASCII\".", "resource://services-settings/remote-settings.sys.mjs", 324))
 0:35.61 GECKO(30963) JavaScript warning: resource://devtools/server/actors/object.js, line 230: debuggee 'resource://gre/modules/ContentDOMReference.sys.mjs:75' would run
 0:35.61 INFO Console message: [JavaScript Warning: "debuggee 'resource://gre/modules/ContentDOMReference.sys.mjs:75' would run" {file: "resource://devtools/server/actors/object.js" line: 230}]
 0:37.00 GECKO(30963) JavaScript warning: resource://devtools/server/actors/object.js, line 230: debuggee 'resource://gre/modules/ContentDOMReference.sys.mjs:75' would run
 0:37.00 INFO Console message: [JavaScript Warning: "debuggee 'resource://gre/modules/ContentDOMReference.sys.mjs:75' would run" {file: "resource://devtools/server/actors/object.js" line: 230}]

Comment 1

[Julian Descottes [:jdescottes]]

Looking at the video we can notice that source tabs keep being renamed, added, all named source + a number, meaning we are in eval'd code.

Here we are debugging code which is evaluated in content processes thanks to SpecialPowers.spawn, which might explain why we see that.
And we also know that we have slightly regressed our behavior for pausing frames with EFT (cf bug 1833637).

Edit: would be interesting to try to set devtools.every-frame-target.enabled to false and see if that helps.

Comment 2

[Julian Descottes [:jdescottes]]

Quick need info: can you share the STRs now that the test landed in tree.

While watching the video during triage, Nicolas noticed that the main thread gets selected at the end, and that's where the UI becomes "unpaused", but the thread where you paused should still be "paused". We should definitely improve the UI here to make it clearer that there is a paused thread. We also need to investigate why we switch to the main thread for no reason here.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Sorry for the delay here. The command to run to get this reproduced is the following:

./mach test remote/webdriver-bidi/test/browser/browser_RemoteValueDOM.js --jsdebugger

Before just set a debugger statement in line 187 within that test file. Running the test press continue once, and then once or twice to step over. Moving the mouse around afterward usually triggers the bug immediately for me.

Comment 4

[Alexandre Poirot [:ochameau]]

Bug 1835629 fixed issues around the popup preview trigerring breakpoints.
I tried comment 3 STR with recent m-c and couldn't reproduce.

Henrik, could you confirm this is now fixed?

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I just tested with a build from today and the problem is still persistent when I follow my steps from comment 3.

Comment 6

[Julian Descottes [:jdescottes]]

Alex will take another look

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

As it looks like adding breakpoints anywhere within the MarionetteCommandsChild actor implementation triggers this bug. It's even not necessary to click or step-through before. Just moving the mouse around or waiting a bit is enough, but also makes it very hard to debug that code.

Comment 8

[Alexandre Poirot [:ochameau]]

The issue happens when you open the browser toolbox and only open the debugger.
Then pause in any thread other than the main thread, then hover a symbol with a reference to a DOM Element.
When you hover over we initialize the inspector panel, which will automatically select an element from the top level target:
https://searchfox.org/mozilla-central/rev/146638366864f73ee8a697ea76480eb02c00eb3c/devtools/client/inspector/inspector.js#374-376
This would ultimately cause to select the toplevel target over there:
https://searchfox.org/mozilla-central/rev/146638366864f73ee8a697ea76480eb02c00eb3c/devtools/client/framework/toolbox.js#3876-3885

May be the inspector should try to select a node within the currently selected target instead?
And/or make it so that when the debugger opens the inspector, it would select the highlighter node right away.
The debugger uses this code to highlight an element:
https://searchfox.org/mozilla-central/rev/146638366864f73ee8a697ea76480eb02c00eb3c/devtools/client/framework/toolbox.js#3836-3841
It would be nice if the highlight would be done as part of inspector initialization or if the inspector wouldn't highlight during this particular initialization.
Toolbox.loadTool accept options, but as of today, the inspector doesn't interpret any option.

STR:

• open the multiprocess browser toolbox on the debugger by default (it is important to NOT open the inspector)
• load data:text/html,<script>document.documentElement; debugger;</script> in a tab
• the debugger pauses in the browser toolbox
• hover document.documentElement
• the preview toolbox shows
• hover the <html> preview

AR: the inspector loads and reset the selected target. The yellow warning about being paused is hidden.
The web page target is still paused, but the parent process target get selected. This is visible in the threads panel.

ER: you stay on the web page target and the yellow warning stay visible.

Comment 10

[Julian Descottes [:jdescottes]]

(Nicolas: just moving the ni? from Bug 1949019)

Comment 11

[Nicolas Chevobbe [:nchevobbe]]

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

(Nicolas: just moving the ni? from Bug 1949019)

Looking

---

The regular toolbox is impacted too, you can see it with the following steps:

1. Go to https://ffx-devtools-thread-change-on-dom-preview-hover.glitch.me/
2. Open the debugger directly without opening the inspector
3. On the page, click the "Pause in Debugger" button
4. In the debugger, hover the target inline preview to trigger the highlight

-> Main thread gets selected

Comment 12

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Bug 1837480 - [devtools] Prevent thread change when hovering element preview in Debugger. r=#devtools.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b87c2b36ef20
[devtools] Prevent thread change when hovering element preview in Debugger. r=ochameau.

Comment 14

[Cosmin Sabou [:CosminS]]

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