Bug 1770363 is going to introduce a way to easier toggle the browser toolbox from observing only the parent process -or- everything.
This allows to drastically improve performance when inspecting only the parent process, while also drasdically improve its readability by showing less resources.
But while debugging only the parent process is a typical scenario, debugging one tab content process is another one.
When you have to debug the content process of the current tab, you will have to enable to "see everything" mode, displaying all the content process resources.
It would be handy if the browser toolbox would show only the content process of the currently selected tab and all the window-global of it.

Doing this is significantly more complex than bug 1770363. We need to introduce some generic layer to filter in/out everything based on the currently selected tab, which can change over time.

This new data is passed down to all function filtering in/out the WindowGlobal's.

It would have been easier to re-use sessionContext to augment it with this data.
But it would make sessionContext become mutable whereas it is static today.
It is built once on WatcherActor construction.
And it would still request a SessionData message to update it accordingly in all processes/threads.

TODO: introduce content process filtering method, to prevent creating some content process targets.
May be also something for workers.

This is an option, but having it in the iframe dropdown is probably a better place.

What's stopping this bug from landing? With the removal of the "Browser Content Toolbox" (bug 1593753), it is no longer possible to select only one toolbox. Currently, one has to select all processes (slow!!!!) and then switch to the desired process via the Threads UI in order to get a console to run code there.

Thanks for reaching us about your trouble with the browser content toolbox removal.

These patches are incomplete and a bit flaky. This isn't a trivial feature. We would need to prioritize this to get it landed.

Could you describe your typical usecases?

Are you only using the console?
Is it solely to evaluate JS with privileged/chrome API from a content process?
Is the multiprocess Browser Console also too slow?

Not sure if this is relevant, but you mention using the Threads UI (and therefore the debugger) to be able to execute code, but there is another way: you can use the context selector in the Console input (see screenshot)

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

Could you describe your typical usecases?

Typical use cases are to inspect the state of specific modules in the child process (e.g. after ChromeUtils.import) and/or access privileged properties off the current tab (e.g. tabs[0].content.document.nodePrincipal). Recent example is https://bugzilla.mozilla.org/show_bug.cgi?id=1810573#c4

Are you only using the console?

Yes, in most cases. But sometimes also the Debugger. But the ability to have a (tab-)process-specific console would already help a lot with my use cases.

Is it solely to evaluate JS with privileged/chrome API from a content process?

Yes.

Is the multiprocess Browser Console also too slow?

Yes. There are different things contributing to the perceived slowness:

• First, it is actually being slow. It takes multiple seconds before I can do anything at all.
• One of the causes for the first is that I have many Firefox tabs & windows open. That hogs a lot of memory, and consequently some memory is swapped to disk (on my mac). When the devtools tries to connect to every process, the memory usage shoots up and lots of swapping occurs, which contributes to the significant delays.
• Secondly, the console is near unusable when connected to all processes, because it seems to aggregate many logs (errors, warnings, requests). This logspam makes it difficult to use the console as a REPL and to relate the output to previous output.

Regarding implementing this feature. I (re)started looking at bug 1648499, which would also significantly help by simplifying the process-helper module where we would need to add some new logic to filter in/out the various content processes.
Unfortunately, this requires some more work than expected.

I'm wondering if there is some alternative UX which would be easier to provide.
I've always wanted to provide a "privileged evaluation" in the regular webpage devtools, enabled by explicit request for firefox developers.
So that you can at least have access to all chrome-only attributes and docshells as well as browsing context objects.
This isn't super trivial either, and wouldn't address the usecase of the debugger, but may be less work.