Like the other media.cubeb.* prefs, it doesn't need to be a VarCache pref.
MozReview-Commit-ID: A2L8Tf3GAt
--HG--
extra : rebase_source : 86791123613c2f21e4a771c99cb079125495dec3
Test that playback works if we don't block, doesn't if we do block, and does
if we do block and CORS is used.
MozReview-Commit-ID: 9PTZXLOdHIU
--HG--
extra : rebase_source : 9071542f9deb36063aa0de3386a75bc0ad111d20
There's no compelling use case for mid-flight redirects, and Chrome
already blocks it, so there's little point in maintaining it.
Add a hidden pref to toggle blocking, so we can toggle it off during
testing to ensure that we're blocking a working mid-flight redirect.
MozReview-Commit-ID: EnGNmYFr8Uv
--HG--
extra : rebase_source : 3ed71273da24f8f0c8bc24ceede49afa7775650d
Spec: https://webaudio.github.io/web-audio-api/#dom-audionode-channelcount
Google has written a web platform test this is going to be merged soon (we
currently fail it).
MozReview-Commit-ID: 1RpASaIJrhm
--HG--
extra : rebase_source : 42dc8af6e677831d70e84ffc23e738d49549c59d
extra : amend_source : b4c30805157bd9bfd06afdfc8f439fe8de1b6aae
extra : source : e7b5b629fb30c4c8b8708979e926029f4e743420
A lot of our thread pools use the default stack size for the platform
they're on, which can be rather large (8MB, usually, on Linux and OS X)
and is probably too much for the typical thread in the thread pool
regardless. SharedThreadPool already has some logic for selecting a
reasonable stack size for worker threads; let's move that logic to
nsIThreadManager so that logic (and constant) can be shared more
broadly. (That we already have a couple of instances of
SharedThreadPool usage solely for this constant suggests that it is a
concept that should be available in a more central location.)
The previous assertion was from an earlier developer stage which changed
during development of bug 1299515. It assumed that mDeviceEnabled was
updated only after passing the assert.
In the final version of bug 1299515 that is no longer true, and
both the failed and the successful device operation asserts
can now be unified to one.
MozReview-Commit-ID: KMdnIs0UgPr
--HG--
extra : rebase_source : 936900db168623f913aaa76a9148d4ee80157493
This is already true for the audio sources. It should be for all.
Crashtests showed that shutting down amidst the async init can lead to
double-stops. It is impossible to completely protect yourself from them without
waiting for all queued operations to resolve (results to become known) before
taking action. Doing that would require a refactor in MediaManager and cause
higher latency for device operations so it seems like the wrong way to go.
MozReview-Commit-ID: 5Cci6whzTL7
--HG--
extra : rebase_source : f4dccbc5a56e33ecc54d63ddefbae43d90ee95d4
extra : source : f5cc71d38e4a7c0e4db830242c1d454fcbdb9e48
extra : histedit_source : 3cd8615054ce9935047e4168c3a472152792886b
This so that SourceListener can keep its internal state in sync with the result
of the start operation.
MozReview-Commit-ID: Cgl5TFnpCeW
--HG--
extra : rebase_source : e2cec60544efcc27c9c8c077fbdb013a8f3b848c
extra : source : 6c38cc382d2114199842dddb14097be8b6d9a961
extra : histedit_source : 00ef8da067eb484b8c5926d008f00f1e9f006e6f
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