Using DevTools on Firefox debug builds is very slow, especially the frontend (Toolboxes and tools).
One possible way to make debugging debug builds easier would be to make the --js-debugger command to use another Firefox binary. Another binary which would be a regular optimized build, running at full speed. So that the only DevTools code to run on the debug build would be the server and actors. This part of devtools should hopefully be fast enough to run smoothly on debug builds.

The main challenges here are:

• to find a way to pass the path to this other firefox executable. We could use a preference, a command line argument and even probably something else (mozconfig,... who knows?)?
• document or warn in the product about possible backward compatible breakage. We should suggest to use the same version of Firefox. I imagine that it will be easy for a developer to pass a release build while debugging a nightly one. We should probably reject that or put extra warnings in the browser toolbox.

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

Using DevTools on Firefox debug builds is very slow, especially the frontend (Toolboxes and tools).
One possible way to make debugging debug builds easier would be to make the --js-debugger command to use another Firefox binary. Another binary which would be a regular optimized build, running at full speed. So that the only DevTools code to run on the debug build would be the server and actors. This part of devtools should hopefully be fast enough to run smoothly on debug builds.

I also like this as an option to inspect a local build that's broken bad enough to also break the browser toolbox (or cause some level of doubt that the tool is broken). You can currently do this but it requires jumping through hoops, something like:

# Start a normal instance with the debugger server running
./mach run --start-debugger-server 6080

# Run the Browser Toolbox instance
MOZ_BROWSER_TOOLBOX_PORT=6080 /Applications/FirefoxNightly.app/Contents/MacOS/firefox --profile /tmp/browsertoolbox -chrome chrome://devtools/content/framework/toolbox-process-window.html

The main challenges here are:

• to find a way to pass the path to this other firefox executable. We could use a preference, a command line argument and even probably something else (mozconfig,... who knows?)?

What about an optional argument to --jsdebugger? So --jsdebugger alone continues to use this binary and --jsdebugger=/Applications/FirefoxNightly.app/Contents/MacOS/firefox lets you point to another one.

• document or warn in the product about possible backward compatible breakage. We should suggest to use the same version of Firefox. I imagine that it will be easy for a developer to pass a release build while debugging a nightly one. We should probably reject that or put extra warnings in the browser toolbox.

I think if we do this we should support opening in non-local builds (because of the point above about broken local builds). We could recommend Nightly in docs to limit compatibility issues. That said, there are DevTools specific compatibility issues that come up, but also profile-downgrade compatibility issues. IIRC we usually clone a profile for using the browser toolbox and then reuse it. We wouldn't want to do that if we are going to open in different versions of Firefox since we'd be downgrading the profile to an older version. Maybe when using an external binary we should always use a temp profile, or something like that?

Here is a quick video of chrome's development workflow which might help us think through some of the desired dx

https://www.loom.com/share/868802d548ef41f39f1925b3f4b8428c

https://hg.mozilla.org/mozilla-central/rev/62a0c9478669