Sites which are whitelisted should be allowed to autoplay audible media.
So check whether a HTMLMediaElement's owner doc's principal has an exact
"autoplay-media" permission. This ensures whitelisted origins can autoplay,
but sub-origins of whitelisted origins need their own permission.
MozReview-Commit-ID: 2IO5KIyplEa
--HG--
extra : rebase_source : 4d9afdec0caa4a82b53bedfd645f259a5c760e4d
Currently, the new init segment provided following a call to changeType() must contain the same number of audio and video tracks as previously.
The Chrome team has indicated concerns in regards to this restriction. TBD.
MozReview-Commit-ID: 3S6YVtQILF9
--HG--
extra : rebase_source : 59574301d8d4b6f04fc40a97a0917222f1d42fe4
Non functional code.
SourceBuffer.changeType allows to reconfigure a sourceBuffer so that a new codec type or new container format can be fed later.
The new code is placed behind the media.mediasource.experimental.enabled pref.
MozReview-Commit-ID: 5wj6J4uzLbA
--HG--
extra : rebase_source : b6f57246e0a4c856f6365bb0c8ec8d759a770105
Additionally, show the number of channels and the sampling rate.
MozReview-Commit-ID: L067Hbv0bXz
--HG--
extra : rebase_source : 193482c7e96b0094ec4d717a9cc30e371067aa1d
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
We made NotifyPull parallel to try to lower the load, and we initially measured
an improvement. However, we did the measurements with a profiler that did an
aggregation of the results. Our results had an high variance, so the mean load
was in fact not meaningful.
More careful measurement performed without doing any aggregation show that,
under load, relying on the fact that the scheduler schedules the tasks on time
is too risky, and that the code is fast enough to not have to parallelize.
MozReview-Commit-ID: CMhSn8Sc0OO
--HG--
extra : rebase_source : cfb41f861089bce9e10446bee81c13f8565ba90e
ProtocolName() is only used for producing error messages and annotating
crash reports. But examining actual crash reports that would have used
the result of ProtocolName() indicates that we can always tell what the
erroring protocol is due to the stack backtrace. So having this virtual
function around just provides duplicate information, and it takes up too
much space in the vtable besides. Let's get rid of it.
Bug 1435133 introduced a new path where we block autoplay and reject the play()
promise, but we didn't fire a "pause" event. This confuses YouTube's controls.
Additionally, even if we're not in a user generated event handler, we
unilaterally consider the media element blessed if execution reaches here:
https://searchfox.org/mozilla-central/rev/11a2ae294f50049e12515b5821f5a396d951aacb/dom/html/HTMLMediaElement.cpp#4110
We previously rejected before reaching here when not in a user generated event
handler, but now if play() is called before we've reached loadedmetadata, we
reject the promise if we're not in a non-event handler and bail out early, and
so we'll bless even if not in a user generated event handler. Meaning when we
do reach loadedmetadata, we think we were in a user generated event handler
when play() was originally called, and so we won't reject the play promise.
So this patch ensures we dispatch a "pause" event when we reject the play()
promise here. The WHATWG spec says we should do this when pausing anyway.
Note: calling our interal Pause() function when rejecting the play() promise
here breaks YouTube, as if we do that we fire a "timeupdate" event. So I opted
to manually code to fire the event here instead of just calling Pause()
everywhere we want to ensure we're paused.
MozReview-Commit-ID: 1snkiTnPGih
--HG--
extra : rebase_source : 2c5ca6c0ed7c2dff2fb971cd159cfdc12a8a227f
Use it like this:
MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_LOG=MSGTracing:5,sync,raw MOZ_LOG_FILE=trace.log ./mach run
Now open `chrome://tracing` and load the file.
Lanes are threads, thread 0 is the audio callback thread, the other thread have
normal numbers.
Thread 1 shows the theoretical budget we have for a particular audio callback.
MozReview-Commit-ID: 87woGiFT4ID
--HG--
extra : rebase_source : 03cefb8edf12b077607ae71aeb999fd0ac966674
extra : source : 14929579ba3f71f14c9d81b6ed88563d35da11e0
This outputs to MOZ_LOG and using an MPSC lock-free queue so we can log to a
particular module from any thread.
MozReview-Commit-ID: INtlki4PEJs
--HG--
extra : rebase_source : c1d488fdd65bfa7ede12c12004921415aaaa1d55
extra : source : f9482471bbd83882f8da3f0ce929f72858abfa04
Cosmin Sabou
Alex Chronopoulos
Dorel Luca
Chris Pearce
Jean-Yves Avenard
arthur.iakab
Tiberius Oros
Matthew Gregan
Kris Maglione
Paul Adenot
Mark Banner
Karl Tomlinson
Jean-Luc Bonnafoux
cubouyaka
Andreea Pavel
David Major
Brindusan Cristian
Tom Ritter
Andrea Marchesini
Nathan Froyd
Bryce Van Dyk
shindli
Boris Zbarsky
Nico Grunbaum
Byron Campen [:bwc]