During the Berlin's fission workweek, we were suggested to add a way to set a breakpoint from the command line.
This actually sounds very handy for a couple of reasons:

• it makes it easier to break. You don't have to find your source, find the function/line in the debugger UI, and click on that line to set the breakpoint. If you know the file and line, you can just pass that as a command line argument or any equivalent (I can only think about environment variable?).
• it would allow setting early breakpoint more easily. For now, you have to run Firefox a first time, go and set the breakpoint in the browser toolbox and restart. If we offer this feature, we would be able to break on the first run.

We might need some more work in order to set "early" breakpoint. The current implementation of --js-debugger doesn't ensure settings the breakpoint / starting the thread actor the earliest possible. I believe that the command line argument is processed early, but the process of starting the debugger server is async and we aren't waiting for it to complete before resuming Firefox startup execution. We may need the unsafe synchronize trick as we do for xpcshell in order to get early breakpoints to work.

This sounds really useful, thanks for working on this Alex!
Honza

Jason, I'm having an issue with this patch.

This allows to set breakpoints from the command line, like this:
./mach run --jsdebugger --breakpoint chrome://browser/content/browser.js:1704

It allows to break on this code:
https://searchfox.org/mozilla-central/rev/23f836a71cfe961373c8bd0d0219ec60a64b3c8f/browser/base/content/browser.js#1702-1710

It does work if I set the breakpoint on line 1704, but not on line 1702, nor line 1703:
./mach run --jsdebugger --breakpoint chrome://browser/content/browser.js:1702

This is quite unexpected, especially when you aren't using the UI to set the breakpoint.
I imagine that the breakpoint sliding is currently done on the client side, thus, preventing me to do much here...
Or is there anything I can do from the actor side of things?
Could it be something that VSCode integration had to deal with in order to set breakpoints? If yes, how?

Otherwise, the breakpoint isn't displayed in the debugger UI, but that sounds like yet another issue.

It is only possible to add a breakpoint on a line with breakable locations. In this case 1702 and 1703 do not.

1704 is the first line in the function to have a breakable location.

I am a bit concerned about this patch because setting breakpoints via the server makes it difficult to clear the breakpoint. Note that the breakpoint is not visible in the UI.

I wonder if we could address the same issue by registering the breakpoints in the server? We currently register them via the client here

https://searchfox.org/mozilla-central/source/devtools/client/debugger/src/client/index.js#23-29

This work might be made simplier to do thanks to bug 1573327, which we will have to do soon for Fission support.
Having breakpoints set once, via the Watcher Actor, may change how we reason about breakpoints.
And this is clearly related as bug 1573327 will help setting early breakpoint in processes. So that a breakpoint is correctly hit, even if the targeted module is executed very early during process startup.