Vorbis.acm seems to be somehow injecting itself into our process, and also the
Flash process, and intercepting the system audio APIs. Version 0.0.3.6 seems to
be crashing, and it's an obsolete version, so we should block it to stop it
crashing us.
MozReview-Commit-ID: Hk93kG0Ly4Q
--HG--
extra : rebase_source : b16dd8decdc8a767bd84f28a009667b4d79677d8
These are the only 2 definitions of the hg.mozilla.org certificate
fingerprint in mozilla-central. The certificate changed on
2016-09-26. So update the fingerprints.
This /might/ be a cargo cult because automation should be pinning
the hg.mozilla.org certificate everywhere. An alternative to this
commit would be to remove the fingerprint pinning from these
scripts. But if these scripts are run by humans, we may want to keep
the pinning in.
MozReview-Commit-ID: 4FUhAGc2oqx
--HG--
extra : rebase_source : fa8889ffbb70c14270acde67121192f7c1932258
If we don't catch HTTPError, the whole job fails since we get an uncaught exception.
MozReview-Commit-ID: 8jwW7ZSieyC
--HG--
extra : rebase_source : a184fe32bb73e786bd874a1c5f298d2b2c0bca83
This was regressed by bug 1296397 which stopped setting the GECKO_HEAD_REPOSITORY and
the like. It wasn't caught because the task doesn't actually depend on those environment
variables except when using the interactive loaner.
This patch supports vcs checkout regardless of whether the task runs from source or not.
MozReview-Commit-ID: CDxdG8G6JDd
--HG--
extra : rebase_source : 8a3d380c86bbfabe6d76854fd8af8e794e75970e
If we happen to pass the current scope (`this`), the browser-loader codebase fails
when passing it as sandboxPrototype. It only works when passing an xray wrapper.
The document scope happen to not be an xray when using the addon, whereas `window`
always is no matter if we are using the addon or not.
MozReview-Commit-ID: GjYHkaCGBDd
--HG--
extra : rebase_source : 7ab2cd164cd4b235de24b74d58a4962f1d1961e6
When NativeKey tries to remove a char message from the queue, another NativeKey instance might be created due to odd API hook or something. In such case, the old instance should handle the received message and the new instance should do nothing for keeping the order of message handling.
This patch makes:
* NativeKey::GetFollowingCharMsg() store removing char message to mRemovingMsg before calling PeekMessage() with PM_REMOVE.
* NativeKey::InitWithChar() set the old instance's mReceivedMsg to the received char message and do nothing even if HandleCharMessage() is called later.
* NativeKey::GetFollowingCharMsg() return received char message if mReceivedMsg is set during a call of PeekMessage().
MozReview-Commit-ID: KXYW0GgC9AY
--HG--
extra : rebase_source : 08472dec28e93450cd04a367843c1511cb812a9c
For detecting nested creation of NativeKey instances, NativeKey should manage the latest instance with sLastestInstance for the other instances and previous instance with mLastInstance.
MozReview-Commit-ID: BFZ0cr1640S
--HG--
extra : rebase_source : e2439a21f5984c6246283924c2013038c734ae2a
It's not obvious how to listen to individual errors in most cases, so
we just link to the reports for now. Progress!
MozReview-Commit-ID: 8nGRJdpzZnO
--HG--
extra : rebase_source : e81c9b29cb03c5ba73e793512525b5c9c68ab655
extra : amend_source : ce1e2368d43d37cab8fe41cd7a978342ad3e2ea6
