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
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
userTypedClear was used for two cases:
1) to keep track of whether we were in the middle of a loadURI call. This use is replaced by inLoadURI, which is
more sane when using e10s (though it's hard to be precise there because we're sending all web navigation calls to
the content process and this introduces a degree of asynchronousness that we just have to live with...).
2) to keep track of whether we were between a network start and a corresponding network stop, and whether the user
typed since the load properly started. This is now tracked on a small object on the browser binding, which has
appropriately named method so we're not just incrementing some magic number but actually understand what
we're saying, and so the information we get out (did the user type since this load started or not?) makes sense.
Note that we're keeping userTypedClear in session store information in order to remain backwards compatible.
It becomes a simple boolean-stored-as-int (1 or 0) that indicates whether we quit/crashed/stopped while a load
was pending, or not.
MozReview-Commit-ID: 5NbmVueocC7
--HG--
extra : rebase_source : 55cd9f3513c0a985580957a5157d47853a8822bf
extra : source : 386b9c750bd2ed458112acd29eb72e4e1371af9d
userTypedClear was used for two cases:
1) to keep track of whether we were in the middle of a loadURI call. This use is replaced by inLoadURI, which is
more sane when using e10s (though it's hard to be precise there because we're sending all web navigation calls to
the content process and this introduces a degree of asynchronousness that we just have to live with...).
2) to keep track of whether we were between a network start and a corresponding network stop, and whether the user
typed since the load properly started. This is now tracked on a small object on the browser binding, which has
appropriately named method so we're not just incrementing some magic number but actually understand what
we're saying, and so the information we get out (did the user type since this load started or not?) makes sense.
Note that we're keeping userTypedClear in session store information in order to remain backwards compatible.
It becomes a simple boolean-stored-as-int (1 or 0) that indicates whether we quit/crashed/stopped while a load
was pending, or not.
MozReview-Commit-ID: 5NbmVueocC7
--HG--
extra : rebase_source : f87199c77094c24c132e6c88f751a5b5d5aa62f9
This adds tests for issues brought up in bug 231393, bug 264610, bug 302575 and bug 1129564,
all of which fed into the current implementation of userTypedClear/userTypedValue. I intend
to move us away from userTypedClear, but I'm keen not to regress any of these issues, so
I'm adding automated tests to ensure that doesn't happen.
MozReview-Commit-ID: 1up2MIXzkzG
--HG--
extra : rebase_source : 4d37f13895b8c7e7aba5331664718582c6b2136c
