Right now the Browsing Context in the parent does not withstand a tab remoteness change.

To perform a remoteness change, one simple way is to navigate to a normal page in a tab, and then load about:about on it (which is a page that loads in the parent).

The remoteness change at the moment is done by removing the <browser> from the DOM, changing the remote attribute and reinserting it. [1]

[1] https://searchfox.org/mozilla-central/rev/b29663c6c9c61b0bf29e8add490cbd6bad293a67/browser/base/content/tabbrowser.js#1650-1659

I imagine that the expected behavior should be that the BC remains the same, similar to how a process switch would keep it. This way we can use the BC (or BC.id) as the de-facto tracker of things across loads in the parent process)

(See bug 1519335 for context on one example where this is needed)

(In reply to :Felipe Gomes (needinfo me!) from comment #0)

The remoteness change at the moment is done by removing the <browser> from the DOM, changing the remote attribute and reinserting it. [1]

[1] https://searchfox.org/mozilla-central/rev/b29663c6c9c61b0bf29e8add490cbd6bad293a67/browser/base/content/tabbrowser.js#1650-1659

By the way, I think we don't need to remove the browser from the DOM anymore now that it's using a Custom Element and not XBL (bug 1441935). My understanding is that this was done to force the XBL constructor/destructor to run without waiting for a layout flush, and now we do handle the attribute flip directly while it's connected: https://searchfox.org/mozilla-central/rev/b29663c6c9c61b0bf29e8add490cbd6bad293a67/toolkit/content/widgets/browser-custom-element.js#29-32. I'm not positive about it though (there's frameloader changes in C++ that happen when the element is added / removed that could still be relevant), so it'd need testing and I didn't want to make that change in bug 1441935.