Seems to return a stale id. The browsingContext in general seems to behave differently in the file: case.

Loading files via file:// is done in a sandbox, and as such causes a remoteness change. This definitely changes the browsing context id (similar when loading about:) pages. Note that a temporary browsing context is created first and immediately destroyed before the final one is created.

Hmmm, so maybe navigate is returning the id of the temporary context in the file: case, but instead it should return the id of the final one.

It might be helpful to check what we do in Marionette because there we have support for the file:// protocol.

Bug 1550571 will fix this.

Paul, the description of the pref says only for non-fission windows. What happens when Fission is enabled?

I think that (but arn't certain) fission should Just Work. I don't remember if that's because it has other code to do this kind of thing, or if browsing context preservation is always enabled for fission. I'm going to leave the NI open for me to remember to test it.

Ok, lets wait until your patch on bug 1550571 has been landed. I will make it easier to test.

Note that there is a bigger problem here. When navigating to file:// URLs the methods in the page content domain (eg. getFrameTree) never get called. As it looks like the remote agent lost the connection.

Enabled content domains will also not be destroyed properly when navigating to a file:// URL. This can lead to leaks and test failures in debug mode.

The "remote:destroy" message is emitted on the message manager from the parent process but doesn't reach the existing content domains.