A check for the customizemode attribute was added to SessionStore.restoreTabContent
back when we removed the about:customizing preloading hackery in bug 1014185. This
was added to prevent the extra work of unnecessarily restoring the content for a
tab that was in customize mode (since the content is actually hidden).
However, there are ways for a user to attempt to browse away from customize mode
in the current tab - for example, going to their Home page with Alt-Home. When
we do this in e10s mode, we do a "remoteness flip" to make the hidden about:blank
browser be remote, which causes us to go through the SessionStore machinery to
do the session swap to the new remote browser. The problem is when we hit the
restoreTabContent part - we hit the condition where the customizemode attribute
is set to true, and then we bail out, which means we never finish the swap. We're,
at this point, in a half-restored state that never resolves.
This patch makes it so that in restoreTabContent, if loadArguments is not null (so
we've been given arguments on where to send the browser _next_ on top of its newly
restored history), we don't skip just because the customizemode attribute is set.
MozReview-Commit-ID: HwW7y2EKJvn
8cb7232e19