Bug 1291860 - Don't flip remoteness of pinned tabs on session restore. r?mikedeboer
The initial browser of new windows starts remote now. When restoring a session,
if we're restoring content into the initial tab and it's going to be loaded
on demand, then we would flip it to non-remote so that it can't background crash.
We'd do this for pinned tabs too, which is silly, since pinned tabs load ASAP.
This patch causes us to skip the remoteness flip if the tab we're restoring
is pinned.
MozReview-Commit-ID: 9eQzfLADzlQ
--- a/browser/components/sessionstore/SessionStore.jsm
+++ b/browser/components/sessionstore/SessionStore.jsm
@@ -3209,27 +3209,18 @@ 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);
- }
+ this._maybeUpdateBrowserRemoteness(Object.assign({
+ browser, tabbrowser, tabData }, options));
// 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);
@@ -3614,16 +3605,60 @@ var SessionStoreInternal = {
}
SessionSaver.runDelayed();
},
/* ........ Auxiliary Functions .............. */
/**
+ * Determines whether or not a browser for a tab that is
+ * being restored needs to have its remoteness flipped first.
+ *
+ * @param (object) with the following properties:
+ *
+ * browser (<xul:browser>):
+ * The browser for the tab being restored.
+ *
+ * tabbrowser (<xul:tabbrowser>):
+ * The tabbrowser that the browser belongs to.
+ *
+ * tabData (object):
+ * The tabData state that we're attempting to
+ * restore for the tab.
+ *
+ * restoreImmediately (bool):
+ * true if loading of content should occur immediately
+ * after restoration.
+ *
+ * forceOnDemand (bool):
+ * true if the tab is being put into the restore-on-demand
+ * background state.
+ */
+ _maybeUpdateBrowserRemoteness({ browser, tabbrowser, tabData,
+ restoreImmediately, 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.
+ //
+ // Note that pinned tabs are exempt from this flip, since
+ // they'll be loaded immediately anyways.
+ if (browser.isRemoteBrowser &&
+ !tabData.pinned &&
+ (!restoreImmediately || forceOnDemand)) {
+ tabbrowser.updateBrowserRemoteness(browser, false);
+ }
+ },
+
+ /**
* Update the session start time and send a telemetry measurement
* for the number of days elapsed since the session was started.
*
* @param state
* The session state.
*/
_updateSessionStartTime: function ssi_updateSessionStartTime(state) {
// Attempt to load the session start time from the session state