Make sure the mPrivateBrowsingId of Origin Attributes is consistent
between LoadInfo and LoadContext.
For chrome docshell, its mPrivateBrowsingId remains 0 even if its
UserPrivateBrowsing() is true (bug 1278664). So we sync the
mPrivateBrowsingId field in LoadInfo in the same way.
https://github.com/kinetiknz/cubeb/commit/6b2c610 changed the output unit
from kAudioUnitSubType_DefaultOutput to kAudioUnitSubType_HALOutput because
capture is never available on the DefaultOutputUnit. For the case where
we're doing output only to the default device, this regressed the automatic
device switching when the output device was changed in the Sound system
preferences. Reverting to the DefaultOutputUnit for this case restores the
previous behaviour. This addresses BMO #1278612.
SetDormant() checks IsShutdown() and |mState == DECODER_STATE_DORMANT|.
So ReaderSuspendedChanged() can just call SetDormant(mIsReaderSuspended) to do the work.
MozReview-Commit-ID: J7Dzsm8IhIS
--HG--
extra : rebase_source : c8a0bc31071bfbe084c2a5f47821c0dc3cfd0860
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
This misspelling was introduced in bug 1125767, changeset b9951cca6d1f.
MozReview-Commit-ID: KQNlLelY2Kn
--HG--
extra : rebase_source : 7b2b8379da23b06737b462dd4c316b5758d807a9