Change functions definitions to generators where yield is used, and drop of non-standards if statement in catch.
List translation/cld2/cld-worker.js as ignored now, as it is a generated file.
MozReview-Commit-ID: wbkjx67fox
When a content process crashes for a tab that is not currently visible to the user (which
can occur if the user is looking at only non-remote tabs, or tabs in other content processes),
then we will only show the tab crash page for the first crashed tab that is selected
by the user. The rest of the tabs will restore on demand.
MozReview-Commit-ID: 1JBAp8diHXp
We have an unused "telemetry" variable. Use this variable and move
the telemetry assignment to immediately after the operation it is
recording.
While I was here, I also cleaned up the timing variables. I eliminated
the end time variable and moved the declaration of the start time
variable so its scope is shorter.
MozReview-Commit-ID: IbGOK5pPkcR
We have an unused "telemetry" variable. Use this variable and move
the telemetry assignment to immediately after the operation it is
recording.
While I was here, I also cleaned up the timing variables. I eliminated
the end time variable and moved the declaration of the start time
variable so its scope is shorter.
MozReview-Commit-ID: IbGOK5pPkcR
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
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
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
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
