James Long (:jlongster) Reporter
	Description • 9 years ago

We have a hard time debugging the debugger because if we break the debugger, we can't use the browser toolbox debugger because it uses the same code. Half the time we can't use the debugger to debug itself because we broke part of the core functionality.

We'll never be able to debug a lot of the core of the debugger server actors, since they control the debugging server. Even if we use a remote debugger, it's dependent on a working debugger server.

However, it would still be really useful to debug the frontend of the debugger if we could use a different version of the debugger in the browser toolbox. If we could run Nightly, open the browser toolbox and somehow connect to my custom build of Firefox and do Chrome debugging, we could do that.

Since we still don't get debugger server debugging, we should only do this if it's not too complex. It's not worth tons of hacks, but if it's easy enough, it would be cool.

	Panos Astithas (he/him) [:past] (please ni?)
	Comment 1 • 9 years ago

I've been using the browser debugger to debug the debugger frontend by targeting the content toolbox. Why doesn't that work?

If we somehow absolutely need to target a running browser toolbox instance, we would only have to ensure that its process is started with the --start-debugger-server parameter, which we could probably always do in BrowserToolboxProcess._create.

	Panos Astithas (he/him) [:past] (please ni?)
	Comment 2 • 9 years ago

Also: https://gist.github.com/bgrins/a05029721ab01feb4c3f

	James Long (:jlongster) Reporter
	Comment 3 • 9 years ago

(In reply to Panos Astithas [:past] from comment #1)
> I've been using the browser debugger to debug the debugger frontend by
> targeting the content toolbox. Why doesn't that work?

I don't quite understand what you mean. What do you mean by "content toolbox"? The point is that if I mess up the UI for setting breakpoints, I can't ever set a breakpoint, no matter which toolbox I use.

> 
> If we somehow absolutely need to target a running browser toolbox instance,
> we would only have to ensure that its process is started with the
> --start-debugger-server parameter, which we could probably always do in
> BrowserToolboxProcess._create.

I only have loose understanding of these terms, is the browser toolbox the normal devtools for a page? If so why do we need to pass that parameter? The debugger server is automatically started when I open the tools... I think I'm misunderstanding your terms.

	James Long (:jlongster) Reporter
	Comment 4 • 9 years ago

That gist is interesting. When I run the command to run the browser toolbox, I get "connection refused". Where do I tell it what to connect to? It looks like this could work.

	Panos Astithas (he/him) [:past] (please ni?)
	Comment 5 • 9 years ago

If this is about using separate code bases then you are right, what I described above won't help you. So far I have only wanted to debug issues in a debugger frontend that was more or less functioning properly, so the fact that the browser debugger would contain the same bugs wasn't an issue for me. I can see how it would be useful to be able to debug completely broken code however.

Now to explain a bit how the Browser Toolbox works: ToolboxProcess.jsm starts a debugger server and then spawns a new process with a window that loads a bare bones XUL file (toolbox-process-window.xul) that hosts the regular toolbox. That new process then connects back to the first process through the RDP (using the address localhost:6080 by default). So content toolbox (the toolbox that targets a tab) and browser toolbox run the exact same code (ok, there are some small differences in which paths are taken in some cases, but not much) and opening a content toolbox also starts a debugger server.

(In reply to James Long (:jlongster) from comment #4)
> That gist is interesting. When I run the command to run the browser toolbox,
> I get "connection refused". Where do I tell it what to connect to? It looks
> like this could work.

The browser toolbox connects by default to localhost port 6080, which should have a debugger server listening from executing the first command. If you run the two commands from separate workspaces, the first one will be the debuggee in this scenario (the buggy code) while the second one will be the debugger. In fact, you might want to simply use your latest Nightly for the second command, like this:

/Applications/FirefoxNightly.app/Contents/MacOS/firefox -P whatever-profile -chrome chrome://browser/content/devtools/framework/toolbox-process-window.xul --purgecaches --jsconsole

	James Long (:jlongster) Reporter
	Comment 6 • 9 years ago

Thanks for explaining! I fired up my local build and ran "listen 6080" and then ran Nightly with the browser toolbox flags you posted, and I get the connection request dialog. However, when I tell it to connect, the browser toolbox window stays completely blank and nothing seems to happen. I didn't see any errors anywhere, but I bet they are somewhere.

I might be doing something wrong. If that works though, it's exactly what I was asking for in this bug. I don't have a whole lot time to look into it right now but I'll keep it in mind in the future!

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 7 • 9 years ago

I was going to propose something like Panos when I first saw this bug come in last night, but he beat me to it! :)

As Panos mentions, if you are working on a frontend bug in the debugger, there's already a procedure you can follow:

1. Start a browser-ready debugger server, just like the "Browser Toolbox" menu option, in the target Firefox you are developing, using your favorite method (choose one):
  A. ./mach run -P dev --start-debugger-server 6080
  B. in GCLI: listen 6080
2. Using a working Firefox code base (such as Nightly, or whatever "working" might mean for the issue you are fixing), connect to this port (choose one):
  A. ./mach run --profile /tmp/foobar -chrome chrome://browser/content/devtools/framework/toolbox-process-window.xul --purgecaches --jsconsole
    * This option relies on reading the matching port value from a pref[1] in the profile you choose
  B. Using WebIDE, choose "Remote Runtime" from right-hand runtime menu, enter "localhost:6080", and choose "Main Process" in the left-hand project menu.

I believe this should allow you to debug a possibly broken content / tab debugger UI using the Browser Toolbox, since you are hopefully connecting with a UI that functions correctly.

When James mentioned this on IRC, I was also imagining a new, more insane mode: the target Firefox could be told to load a *separate* set of actors for the Browser Toolbox mode from a working code base.  So, the tab toolbox would have potentially broken actors, which you'd be able to debug using the working actors.

However, James pointed out that it may not work for breakpoint issues since you'd be trying to debug a stopped runtime.  Still, it could be useful for some actor issues.

[1]: https://dxr.mozilla.org/mozilla-central/source/browser/devtools/framework/toolbox-process-window.js#22