Bug 1261842 - When putting the initial tab into the restored background state, flip it to non-remote. r?mikedeboer
MozReview-Commit-ID: BX8XbYjJHGf
--- a/browser/components/sessionstore/SessionStore.jsm
+++ b/browser/components/sessionstore/SessionStore.jsm
@@ -3209,16 +3209,28 @@ var SessionStoreInternal = {
let restoreImmediately = options.restoreImmediately;
let loadArguments = options.loadArguments;
let browser = tab.linkedBrowser;
let window = tab.ownerGlobal;
let tabbrowser = window.gBrowser;
let forceOnDemand = options.forceOnDemand;
+ // If the browser we're attempting to restore happens to be
+ // remote, we need to flip it back to non-remote if it's going
+ // to go into the pending background tab state. This is to make
+ // sure that the background tab can't crash if it hasn't yet
+ // been restored. Normally, when a window is restored, the tabs
+ // that SessionStore inserts are non-remote - but the initial
+ // browser is, by default, remote, so this check and flip is
+ // mostly for that case.
+ if (browser.isRemoteBrowser && (!restoreImmediately || forceOnDemand)) {
+ tabbrowser.updateBrowserRemoteness(browser, false);
+ }
+
// Increase the busy state counter before modifying the tab.
this._setWindowStateBusy(window);
// It's important to set the window state to dirty so that
// we collect their data for the first time when saving state.
DirtyWindows.add(window);
// In case we didn't collect/receive data for any tabs yet we'll have to