1734344 - Blank debugger in the MBT after setting a breakpoint on WatcherRegistry.jsm

Status: RESOLVED INACTIVE

(DevTools :: Debugger, defect, P3)

Description

[Julian Descottes [:jdescottes]]

STRs:

• open the MBT
• select debugger
• open WatcherRegistry.jsm
• set a breakpoint on if (!(type in watchedData)) { in addWatcherDataEntry
• close the MBT
• open the MBT

ER: The MBT should open and initialize correctly
AR: The debugger immediately breaks and remains blank. After a while we get the typical split UI with half of the toolbox showing "Browser Toolbox Connection Status"

Note: It's annoying to cleanup those breakpoints for now, so I suggest to reproduce this with a clean temporary profile

Comment 1

[Alexandre Poirot [:ochameau]]

That's because WatcherRegistry is a JSM, whereas ideally, it should probably be a commonjs module.
This would allow to correctly flag the MBT's one with invisibleToDebugger:true and have the ThreadActor and Debugger spidermonkey API to correctly ignore it.
You would have similar breakage if you start putting breakpoints in DevToolsFrame's JSWindow Actor.
While we can probably find some ways around WatcherRegistry, I don't have any solution for DevToolsFrame JSMs, except trying to minimize them to the strict minimum.

Comment 2

[Julian Descottes [:jdescottes]]

(In reply to Alexandre Poirot [:ochameau] from comment #1)

That's because WatcherRegistry is a JSM, whereas ideally, it should probably be a commonjs module.
This would allow to correctly flag the MBT's one with invisibleToDebugger:true and have the ThreadActor and Debugger spidermonkey API to correctly ignore it.
You would have similar breakage if you start putting breakpoints in DevToolsFrame's JSWindow Actor.
While we can probably find some ways around WatcherRegistry, I don't have any solution for DevToolsFrame JSMs, except trying to minimize them to the strict minimum.

Oh right, even though the UI is in a different process and application, the WatcherRegistry for the MBT is still running in the parent process of the target Firefox. And invisibleToDebugger doesn't apply because jsm.

Probably no good solution here, having a way to clean the breakpoints would be a decent workaround.

Comment 3

[Julian Descottes [:jdescottes]]

Could also happen if you break on non DevTools JSMs

Possible workarounds:

• we could skip saving breakpoints in DevTools JSMs (or all JSMs?)
• move JSM logic to commonjs modules (only a small part needs to be a singleton)

Needinfo: can be split in smaller bugs to refactor individual JSMs

Comment 4

[Julian Descottes [:jdescottes]]

Going to close as INACTIVE, if we feel the need to debug a specific DevTools JSM, we should file a specific bug to refactor it to a commonjs module. No need to have a whole meta for this.