At the time tests were enabled they were green. However bug 1440664 which was
inflight at the same time made them have intermittent oranges. Rather than back
out bug 1440664 (which technically landed later) I'm turning off the tests until
we can figure out what's going on.
--HG--
extra : source : d3b20e603c5fe0c96c0d4a0b58a5b189dc7467b8
MediaEngineDefaultAudio uses the SineWaveGenerator and passes a
TrackTicks (int64_t) arg to generate(). It need to take the same type
or bad things can happen.
MozReview-Commit-ID: EoybtTFkWhT
--HG--
extra : rebase_source : c21bbbc2729d092ad78ffe877bf141dbce3a41d3
This test has been disabled because it was failing intermittently with a pretty high
frequency on the Windows platform, the reasons behind the failures have been fixed
in Bug 1435100.
MozReview-Commit-ID: FNJqocBcxnf
--HG--
extra : rebase_source : f5fd1392bc53f137c8e48e433fddd103af74eaad
This test has been disabled because it was failing intermittently with a pretty high
frequency on the Windows platform, the reasons behind the failures have been fixed
in Bug 1435100.
MozReview-Commit-ID: 6Dxm8nTVXgq
--HG--
extra : rebase_source : aa65bd83652b73b632da40be8d23b98d12f511db
On OS-X, this test sees an extra 'No chrome package registered for
chrome://branding/locale/brand.properties"' console warning, which causes it
to inspect the wrong error when checking for location information.
--HG--
extra : amend_source : a51aedad5b11b92f564ea739308000a41ff89578
We currently report a useful location in error reports when extensions fail to
resolve a promise or call a response callback, but in some slightly
less-than-ideal ways. We currently generate a complete stack and parse its
string value (which is expensive), and then report the caller location as part
of the message, rather than as the error's location and stack.
This patch changes that behavior to store a single SavedStack frame, and to
properly report that as the location of the error.
MozReview-Commit-ID: Jmtf4C1O6pW
--HG--
extra : rebase_source : a47795947e1c93934ec3ced29dd6d345937d443e
Currently, when we create an error object at the end of an aysnc operation, we
only get a useful caller location if async stacks are enabled.
This patch changes our behavior to use the saved caller location we've already
stored when creating an Error object based on a plain string message.
MozReview-Commit-ID: DDO0lAUHYRO
--HG--
extra : rebase_source : 995ea3c6de26b616a6cef483b271e222bb2aaf6e
This picks up an existing fix for variant keys, which we started
using in gecko. The lack of this fix broke l10n-merge, and thus
l10n nightlies.
MozReview-Commit-ID: Gy6U52rc6PH
--HG--
extra : amend_source : 8c5e29e877a24558b96dfa18ec5a0ae05a466b93
Websites which collect passwords but don't use HTTPS start showing scary
warnings from Firefox 51 onwards and mixed context blocking has been
available even longer.
.onion sites without HTTPS support are affected as well, although their
traffic is encrypted and authenticated. This patch addresses this
shortcoming by making sure .onion sites are treated as potentially
trustworthy origins.
The secure context specification
(https://w3c.github.io/webappsec-secure-contexts/) is pretty much focused
on tying security and trustworthiness to the protocol over which domains
are accessed. However, it is not obvious why .onion sites should not be
treated as potentially trustworthy given:
"A potentially trustworthy origin is one which a user agent can
generally trust as delivering data securely.
This algorithms [sic] considers certain hosts, scheme, and origins as
potentially trustworthy, even though they might not be authenticated and
encrypted in the traditional sense."
(https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy)
We use step 8 in the algorithm to establish trustworthiness of .onion
sites by whitelisting them given the encrypted and authenticated nature
of their traffic.
