Note that without this, there seems to be no way to read the "browser console" in the new about:debugging tools (the main process is where you'd find that info in the WebIDE implementation). Is that not a concern, now that we're deprecating and removing the WebIDE version?

Given that this could potentially affect GeckoView and browser engineers, what is the effort required for this?

The main process is already supported, just behind the pref devtools.aboutdebugging.process-debugging. We preffed the category off by default because we were not sure it was widely used. We can default to true if needed.

Was implemented in Bug 1522062 for reference.

This bug is for listing all processes.

It was mentioned in #devtools on IRC that listing processes by PID could be useful. The use case was about "find where a particular part of a web extension is loaded".

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

It was mentioned in #devtools on IRC that listing processes by PID could be useful. The use case was about "find where a particular part of a web extension is loaded".

Just to add my comments since I think it was my comment that mentioned this. My use cases are pretty obscure, but might be more common as we move towards fission.

Today what I was trying to do was understand exactly where various extension script content is loaded (ie in which process).
Background runs in the extension process, content scripts run in content processes (all of them! even privileged!) but there are lots of other edge cases I wasn't sure about (e.g. proxy scripts, devtools pages etc)

So my use case would have been something like:

1. open up a Browser Content Toolbox for specific PID [1]
2. Use the file browser in the debugger to inspect which scripts are loaded, and from where

I ended up using about:memory, as this will at least give you the principal (top level url) for each window in each process, but it doesn't tell you what scripts are loaded.

For example in this case, I could see from about:memory that we had a JSrealm in the parent process which corresponded to a background page for an extension. This was worrying as background pages are loaded in the Extension process (not the parent). As it turns out, its not for loading script, just for creating BlobURIs [2]. Not sure debugger would have help me work that out ( Kris told me :).

But I regularly use the Browser Content Toolbox for testing our sandbox which basically just needs:

• the ability to see what resources are loaded
• the ability to see what requests are initiated from this process
• the ability to execute scripts in the content process to simulate a compromised process
• Sometimes debugging, but usually i'm only debugging the parent

Most of the time, Im only focused on regular web content processes, as that is where the main attack is coming from. But having the ability to create a "Browser Content Toolbox" for an arbitrary process would be useful if its possible. (Even just something hacky, like here is a script you can paste into the parent process to spawn a Browser Content Toolbox for a specific PID. Im down in the guts anyways, so I don't need a button for it. )

[1] about:memory is a good way to get all open PIDs, and the process type they correspond too
[2] https://searchfox.org/mozilla-central/rev/cc280c4be94ff8cf64a27cc9b3d6831ffa49fa45/toolkit/components/extensions/ExtensionParent.jsm#671-678

Had several requests for this recently from peers working on GeckoView. Let's try to add a minimal UI showing content processes, behind a pref.

Just a quick note: the Debugger folks recently added a new feature for the Browser Toolbox: you can see content processes in the debugger, and add breakpoints in scripts loaded in those content processes. This should also work when remote debugging a Main process via about:debugging.

This feature is behind the DevTools fission preference: devtools.browsertoolbox.fission. I suggest users waiting on this bug to try this. The feature is still a work in progress, please reach out to us if you do try it and see anything weird!

edit: just wanted to clarify that you don't need fission to be enabled, just the devtools fission pref in the Firefox instance where you run about:debugging.