Over time, we've had lots of reports of the Browser Console janking the rest of the browser. Since it runs in the main process, any delay in rendering the console can also affect the rest of the UI.

There's been a lot of work on improving the perf of the frontend in general, but something else we could do that would presumably help is moving the UI into a another process.

I played around with doing this in the DevTools toolbox more generally, but I ran into a number of issues that made me think it'd be easier to try this with the Browser Console first.

Some notes:

1. As for how to set this up, see https://bugzilla.mozilla.org/show_bug.cgi?id=1523028#c47. I figure we could add a new about page like about:browserconsole, and then set the flags appropriately.
2. It seems we can't read/write to prefs from this process. I'm not sure this is something that's planned to be added, but if not we'd need to have a way to do this (presumably through DevTools protocol or message manager with a whitelist of allowed changes). Or alternatively we could look into using a different storage mechanism that's safe to access from a different process.
3. Various JSMs don't like to be loaded in the content process (XULStore.js, AddonManager.jsm). The full DevTools toolbox loads these, I haven't yet tested with just the console to see if they do.
4. We'll be connecting to a target from another process which we generally support (i.e. in the normal DevTools toolbox UI), but there's probably some additional wiring up that would need to happen here on the DevTools client/server side.

Moving the frontend to another process will only have an impact on the frontend codebase. Releasing a few cycles to render the toolbox from the main thread to a dedicated process. Thus, making the rest of Firefox UI more responsive. And also releasing a few cycle out of the main process to have better data for the netmonitor, for which we record HTTP requests from the main process.

But note that such work won't have an impact on bug 1523937, as the console overhead isn't on the frontend side. The overhead will stay in the main thread.
Typical report of the browser console like bug 1471158 is also server side and will keep slowing down the parent process.
Do you have some other reports related to the browser console that are about the frontend codebase?

Now, that's still an interesting quest to have.
I already looked about 1 year ago on how to run one tool of the toolbox in another process.
I was considering using work from bug 1307765 in order to simplify the instantiation of all panels,
by loading them via an URL with query parameters containing the necessary informations to spawn the DebuggerClient and connect to the right Target (page, addon, process, ...).
so that you could load:
chrome://devtools/content/webconsole/index.html?type=root
(similarly to about:devtools-toolbox?type=root, which loads a browser toolbox like toolbox)
And the document will set it up on its own.

The advantage of this is that you do not need any script next to the document to set it up.
Typically, with OOP, you would have to have some frame script or something to instantiate BrowserConsole/WebConsole class. Whereas here, the document is independant and able to set it up by itself.

Otherwise the challenges I hit while playing with OOP frontend were:

• tooltips. It is far from being clear how to keep them working with OOP. AFAIK, we are still relying on this bit of XUL:
  https://searchfox.org/mozilla-central/source/devtools/client/framework/toolbox.xul#42
• rendering. Getting OOP was involving using <html:iframe mozbrowser>. <xul:browser remote=true> wasn't working for me. And even with mozbrowser frames, I was having rendering issues. There may be better ways to do that now?
• I did not managed to get a decent setup for the debugger client. It is more complex if you consider the toolbox instead of only the browser console, as you have to share the same client between all tools. The OOP tool and the others, still in the parent process. We assume using the same clients/fronts between all tools, so that we have only on actor for the debugged page. If you start spawing a new client in the OOP process, it means we will have more than one console/inspector/thread actor and we don't handle that correctly.

I would be very interested to know if you manage to make chrome://devtools/content/webconsole/index.html?type=root to:

1. Render anything OOP
2. Be able to setup a client out of query parameters
3. Be already somewhat usable if 1 and 2 work and see what else other than tooltip breaks.
4. Everything just work!!

Going OOP only for the browser console is a good idea, it removes tons of issues that we would hit if we start doing it for tools within the toolbox!