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
There's no standard way to create a JS error with full stack and location
information from a saved stack. Since we need this functionality in order to
reject promises with useful Error objects, this patch adds a simple helper to
make that possible.
MozReview-Commit-ID: FyGuo4UjfsQ
--HG--
extra : rebase_source : 65ef11c56f23e04ea5eeb87b972bfc8e4867fdd2
The following tests all hardcoded a special value for Timer Precision Reduction.
browser/components/extensions/test/xpcshell/test_ext_browsingData_cookies_cache.js
browser/components/resistfingerprinting/test/browser/browser_performanceAPI.js
browser/components/resistfingerprinting/test/mochitest/test_animation_api.html
browser/components/resistfingerprinting/test/mochitest/test_reduce_time_precision.html
devtools/client/sourceeditor/test/browser_codemirror.js
dom/animation/test/css-animations/test_animation-currenttime.html
dom/animation/test/mozilla/test_transition_finish_on_compositor.html
dom/media/test/test_video_stats_resistfingerprinting.html
dom/tests/mochitest/ajax/jquery/test_jQuery.html
netwerk/test/unit/test_race_cache_with_network.js
Of these, only test_video_stats_resistfingerprinting.html begins failing when Jitter is enabled.
So disable jitter for that test.
Additionally, dom/midi/tests/test_midi_packet_timing_sorting.html began failing
with Jitter, so we disable it there. (We could easily modify the test so it began
passing, but this would reduce the effectiveness of the test.)
MozReview-Commit-ID: 2kipxV6wYv9
--HG--
extra : rebase_source : f455af2db1bba4e1c3986c413643b549ad29c208
Fuzzytime deterministically generates a random midpoint between two clamped values,
and if the unreduced timestamp is above the midpoint, the time is rounded upwards.
This allows safe time jittering to occur, as time will never go backwards on a given
timeline.
It _is_ possible for time to go backwards when comparing different (but related)
timelines, such as a relative timeline in one page (with its own
performance.timeOrigin) and a relative timeline in an iframe or Worker (which
also has its own performance.timeOrigin). This is the same behavior as the 2ms timer
reduction we previously landed; jitter doesn't make this any better or worse.
MozReview-Commit-ID: IdRLxcWDQBZ
--HG--
extra : rebase_source : 40b29d34e5cc99f9b8e6d5e711a03b9fe9bfa595
With block size 128, rounding `128` to end of next block gives `256`, which is
not what we want when running MSG iterations. That could mean over-iterating and
buffering unnecessary amounts of silence.
MozReview-Commit-ID: vW14l2ygRy
--HG--
extra : rebase_source : 8aeedc8958e646f9730c9163447e3355a73fd42e
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.
