That's my plan, to make it possible for all clients to control this behaviour. I intend for process switching to eventually be universally available, and to allow clients to add callbacks for handling special pre-switch and post-switch actions.

I'm unclear on how this works. I thought that the original JS code didn't have access to browser tabs and so this would have to remain in JS. But it's in C++ with this change and on re-reading it I'm not really following.

I thought that a top level load _is_ one that's in a tab, rather than an iframe. When coudl something be top-level but not in an tab?

I also thought that the JS code that this comes from handled tabs, and couldn't be converted to JS (yet). Which is why I had two seperate bugs. But I'm misunderstanding something about that. @nika could you help me by explaining?

Thanks.

I didn't move exactly this into c++, but instead I added a method to nsIBrowser which implements the intention behind that check, and call that method instead. In the long-run, I intend to remove the need to get the tabbrowser from our embedder element entirely.

I thought that a top level load _is_ one that's in a tab, rather than an iframe. When coudl something be top-level but not in an tab?

There are a number of <browser>s in gecko which aren't loaded in tabs, such as devtools, webextension pop-ups, the browser sidebar, and webextension settings. These browsers are just <browser> elements, and don't have a corresponding tab.

If the call to getTabbrowser() from the old code failed, that meant that the browser which was considering doing a process switch was not loaded within a tab.

I also thought that the JS code that this comes from handled tabs, and couldn't be converted to JS (yet). Which is why I had two seperate bugs. But I'm misunderstanding something about that. @nika could you help me by explaining?

The bits which couldn't be switched from JS to C++ yet are still in JS. I added a couple of extra methods to the nsIBrowser interface, which is implemented in JS, which will perform the relevant checks for us.

GetCanPerformProcessSwitch is the equivalent of checking getTabbrowser() for being non-null, and PerformProcessSwitch is equivalent to SessionStore._doTabProcessSwitch.

I also use the nsIBrowser interface for the getRemoteTypeForPrincipal method, as that is still implemented in JS, and needs to be refactored to be accessible without a nsIBrowser in the future.

This can only happen on the main thread. I can add a MOZ_ASSERT(NS_IsMainThread()), but DocumentLoadListener's methods, in general, are tied to the main thread.

This solution is mainly not-great because I'm just declaring the static inline in this method, and I think it would be nicer if I factored this logic out somewhere where it's easier to follow.