The problem with this test was that it was actually relying on the old
broken behaviour where the initial browser of the new window it opens
would be flipped from remote back to non-remote before loading its
contents and flipping remote again. Because it now starts remote
(and stays there instead of doing all of the extra work), the
test was more likely to fall into the trap that I described in
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/1261842%7Csort:relevance/mozilla.dev.platform/gthFqog3J-M/Ypx-SNhEQgAJ
where the promiseBrowserLoaded was firing for the wrong page
load, which meant that the cookie hadn't had a chance to be
set yet.
I've converted the test to use the properly instrumented
BrowserTestUtils functions which wait for the window to be
properly ready, and it appears to pass on try with multiple
retriggers.
MozReview-Commit-ID: BtQRx7og52A
--HG--
extra : rebase_source : 83a9c36533505167198b62ddc189c6fa62cec8cd
The code that checks to see whether or not we should flip the remoteness of a browser
before loading the session state into it wasn't accounting for the fact that oftentimes,
restoreImmediately isn't included, so it's undefined, which coerces to "false-y".
This caused us to very quickly destroy a TabParent, very soon after creating it. In
some cases, the IPC layer seems to not like that, and throws an OnChannelError,
which causes the TabParent ActorDestroy method to be called with an abnormal
shutdown reason, which causes the tab crash observer to fire, which bubbles the
tab crash event.
We should probably make the IPC layer more resilient to this sort of thing, but
we should also probably not flip remoteness when we really don't need to.
Now instead, when restoring a tab, we detect whether or not it's going to
be restored automatically in the near future. If it's not going to be
restored automatically, and the browser is remote, we flip its remoteness -
otherwise we leave it alone.
MozReview-Commit-ID: 5AmPHvzDZlX
--HG--
extra : rebase_source : 0bfeb2cdb0c5849a65bc9a0855c6209d693e5ff4
The code that checks to see whether or not we should flip the remoteness of a browser
before loading the session state into it wasn't accounting for the fact that oftentimes,
restoreImmediately isn't included, so it's undefined, which coerces to "false-y".
This caused us to very quickly destroy a TabParent, very soon after creating it. In
some cases, the IPC layer seems to not like that, and throws an OnChannelError,
which causes the TabParent ActorDestroy method to be called with an abnormal
shutdown reason, which causes the tab crash observer to fire, which bubbles the
tab crash event.
We should probably make the IPC layer more resilient to this sort of thing, but
we should also probably not flip remoteness when we really don't need to.
Now instead, when restoring a tab, we detect whether or not it's going to
be restored automatically in the near future. If it's not going to be
restored automatically, and the browser is remote, we flip its remoteness -
otherwise we leave it alone.
MozReview-Commit-ID: 5AmPHvzDZlX
--HG--
extra : rebase_source : 9e152c2f1106eda76702bd3ed4cf48e9703e05c8
The code that checks to see whether or not we should flip the remoteness of a browser
before loading the session state into it wasn't accounting for the fact that oftentimes,
restoreImmediately isn't included, so it's undefined, which coerces to "false-y".
This caused us to very quickly destroy a TabParent, very soon after creating it. In
some cases, the IPC layer seems to not like that, and throws an OnChannelError,
which causes the TabParent ActorDestroy method to be called with an abnormal
shutdown reason, which causes the tab crash observer to fire, which bubbles the
tab crash event.
We should probably make the IPC layer more resilient to this sort of thing, but
we should also probably not flip remoteness when we really don't need to.
Now instead, when restoring a tab, we detect whether or not it's going to
be restored automatically in the near future. If it's not going to be
restored automatically, and the browser is remote, we flip its remoteness -
otherwise we leave it alone.
MozReview-Commit-ID: 5AmPHvzDZlX
--HG--
extra : rebase_source : 9e152c2f1106eda76702bd3ed4cf48e9703e05c8
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
--HG--
extra : rebase_source : 5a38290991540152392dcab8f3ae1b2dfa398506
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
We were closing the windows before to improve perceived shutdown
performance, but we end up in a state where we're likely to miss
out on the last ~2 seconds of session activity for most tabs per
window. This is because we were removing the session update
message listeners and resolving the flush Promises once the
domwindowclosed notification fired for the window.
Hiding the window allows us to wait for the messages properly.
What's more, we weren't even collecting the window state after
we had flushed, so we have _always_ been missing (in the worst
case) about 2 seconds of session state per window. This addresses
that.
MozReview-Commit-ID: BEOIHV4EErf
--HG--
extra : rebase_source : a814098c0e3aa2224f5d38327c135aba986b4b80
App tabs load immediately, and so there's no point in causing the remoteness
flipping machinery to kick off by making the pinned tabs non-remote by default.
MozReview-Commit-ID: 48O2mJSHurr
--HG--
extra : rebase_source : 975137009468db697b20f1b05569bc7e0ec48534
