The code landed in bug 1593937 doesn't correctly support navigation to/from the parent process, where the BrowsingContext of the tab we inspect changes to another one.

A few useful notes from Nika about BrowsingContext changes:
re: where BrowsingContext replacement happens
When doing a FrameLoader swap, we read the previous BrowsingContext if we're going to preserve it here: https://searchfox.org/mozilla-central/rev/df94cd5ba431234bc220ac081def0801fe44b89e/dom/base/nsFrameLoaderOwner.cpp#103-106.
We could potentially cache it in a local variable if we aren't planning to preserve at this point as well. We'll have the new BrowsingContext ready & initialized after the block is complete, here: https://searchfox.org/mozilla-central/rev/df94cd5ba431234bc220ac081def0801fe44b89e/dom/base/nsFrameLoaderOwner.cpp#131. It might be reasonable to attach the previous BrowsingContext to the XULFrameLoaderCreated event fired here, though that may cause issues for old-RDM (as it doesn't use a XUL element): https://searchfox.org/mozilla-central/rev/df94cd5ba431234bc220ac081def0801fe44b89e/dom/base/nsFrameLoaderOwner.cpp#157.
Alternatively, it would be possible to do this with an observer notification, but I'd recommend running it under a script blocker with nsIObserverService::NotifyWhenScriptSafe as (IIRC) there may be a script blocker on the stack while this code is running.

Mostly. It requires fission.rebuild_frameloaders_on_remoteness_change to be true, if fission is disabled, and may not work on Android.
Yeah, it won't work for GeckoView, because they don't use the proper method for doing remoteness updates https://searchfox.org/mozilla-central/rev/fca0be7e2cf2f922c9b927423ce28e8a04b3fd90/mobile/android/chrome/geckoview/geckoview.js#168-176

Tracking Fission DevTools bugs for Fission Nightly (M6) milestone

Tracking dt-fission-m2-mvp bugs for Fission Nightly milestone (M6c)

Bug 1580766 may also help identifying browsing context navigating to another process.

It looks like bug 1647534 started failing because of this limitation. I'll try to have a look.

This allows to better support navigating to a new BrowsingContext within the same Tab.
Overall, framework codebase is tracking a Browser Element and should use browserId.
Targets may end up being specific to one BrowsingContext/WindowGlobal,
so they may rather use browsingContextID.

https://treeherder.mozilla.org/#/jobs?repo=try&selectedTaskRun=GZpt-u4HT6yAUYEU934_GQ.0&revision=ea5153b0688889fafb36fdfd99d84b4e8a296724

https://hg.mozilla.org/mozilla-central/rev/8c68eb688528