Should the media element be cycle collected and a decoder still be active, a change of state could have caused the track list to be re-created causing a cycle between the HTMLMediaElement and the track list.
We also check when potentially updating the ready state if the self reference is still needed.
Place various assertions.
Differential Revision: https://phabricator.services.mozilla.com/D11860
It was possible for two sequential calls to HTMLMediaElement::AddRemoveSelfReference to leave the media element deregistered when it should have registered.
And we ensure to ony ever self register once.
Differential Revision: https://phabricator.services.mozilla.com/D11859
We were clamping the playback rate properly if the decoder had been setup already, but not if setting it before playback started.
Differential Revision: https://phabricator.services.mozilla.com/D11005
There are often websites using videos without an audio track as background image or as GIF-like image. For these cases,
we don't want to hold a wakelock.
Differential Revision: https://phabricator.services.mozilla.com/D7215
HTMLMediaElement::UpdateWakeLock() is responsible for creating and releasing audio wakelock.
HTMLVideoElement::UpdateWakeLock() is responsible for creating and releasing video wakelock.
In addition, each platform would handle system wakelock properly depending on different requests.
Differential Revision: https://phabricator.services.mozilla.com/D7214
Various places in dom/ use the pattern:
already_AddRefed<NodeInfo> ni = ...;
which is supposed to be disallowed by our static analysis code, but
isn't, for whatever reason. To fix our static analysis code, we need to
eliminate instances of the above pattern.
Unfortunately, eliminating this pattern requires restructuring how Nodes
are created. Most Node subclasses take `already_AddRefed<NodeInfo>&` in
their constructors, and a few accept `already_AddRefed<NodeInfo>&&`. We
need to enforce the latter pattern consistently, which requires changing
dozens of source files.
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the
place. Additionally, if moving entries is implemented via memcpy (which
is quite common), PLDHashTable copying around bits *again* is
inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead of
copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
The reason we hit this assertion is that we still connected to Then() and waited for its result when the resolve or reject
runnable which dispatched by ThenValue can't be executed because the target thread had been shutdown.
Therefore, when XPCOM is going to shutdown, we should disconnect the Then() because it might not have a chance to execute
its resolve/reject method.
Differential Revision: https://phabricator.services.mozilla.com/D5893
The MozAutoplayMediaBlocked event should have its target set to the video
element, not the document.
Also, MozNoControlsBlockedVideo event has to initialized from the CustomEvent
constructor of the right window for the XBL binding to access it. I don't know
when it stopped working.
Test is added to ensure the entire UI won't break.
Differential Revision: https://phabricator.services.mozilla.com/D5801
"blocked" event is used for testing.
"MozAutoplayMediaBlocked" event is used for changing the control UI on Fennec.
Differential Revision: https://phabricator.services.mozilla.com/D4267
Since we don't block media without audio track anymore, the original telemetry scalar becomes useless.
We need to change its meaning in order to know the number of allowed autoplay without audio track.
Differential Revision: https://phabricator.services.mozilla.com/D3673
Add two telemetry scarlar,
"MEDIA_BLOCKED_NO_METADATA" records how many media which was blocked because it hadn't loaded metadata yet.
"MEDIA_BLOCKED_NO_METADATA_ENDUP_NO_AUDIO_TRACK" records how many media which was blocked because it hadn't loaded metadata and ended up for being no audio track.
By collecting those data, we can know the proportion of media which should be autoplay but was blocked because of lacking metadata.
Differential Revision: https://phabricator.services.mozilla.com/D3671
The DOM elements within the UA Widget Shadow DOM should have its reflectors in
the UA Widget Scope. This is done by calling nsINode::IsInUAWidget() which
would check its containing shadow and its UA Widget bit.
To prevent JS access of the DOM element before it is in the
UA Widget Shadom DOM tree, various DOM methods are set to inaccessible to
UA Widget script. It would need to use the two special methods in ShadowRoot
instead to insert the DOM directly into the shadow tree.
MozReview-Commit-ID: Jz9iCaVIoij
This prevents XBL binding from being attached, and create the Shadow Root to
host controls to be created by the script.
Shadow Root and the JS controls are lazily constructed when the controls
attribute is set.
Set nsVideoFrame as dynamic-leaf so it will ignore content child frames when
the controls are XBL anonymous content, and handles child frames from controls
in the Shadow DOM. The content nodes are still ignored since there is no
<slot>s in our Shadow DOM.
MozReview-Commit-ID: 3hk41iMa07n
Use new telemetry histogram ID 'AUDIO_TRACK_SILENCE_PROPORTION' to know the proportion of
silent part in the whole audio track.
Differential Revision: https://phabricator.services.mozilla.com/D3066
Since sed on multiple lines ended up being such a pain and I didn't end up
writing a script for this because I didn't think it'd end up being so boring, I
may have made a couple cleanups here and there as well...
Differential Revision: https://phabricator.services.mozilla.com/D2887
This is used to count the potiential number of the blocked autoplay media element without audio track
even if user was enable autoplay.
It might happen on three cases,
1. play -> loadedmetadata
2. loadedmetadata -> play
3. loadedmetadata -> has 'autoplay' keyword
In first case we need to check whether the play invocation has been called, and check other other cases
before the media starts playing.
In addition, the scalar name isn't consist with other names is because of the 40 maximum limitation of
the ping name.
MozReview-Commit-ID: 6Qm6TD4ME8I
This is used to count the potiential number of the blocked autoplay media element without audio track
even if user was enable autoplay.
It might happen on three cases,
1. play -> loadedmetadata
2. loadedmetadata -> play
3. loadedmetadata -> has 'autoplay' keyword
In first case we need to check whether the play invocation has been called, and check other other cases
before the media starts playing.
In addition, the scalar name isn't consist with other names is because of the 40 maximum limitation of
the ping name.
MozReview-Commit-ID: 6Qm6TD4ME8I
Various web authors have expressed desire to know in advance whether autoplay
will work.
They want this in order to avoid paying the price for downloading media that
won't play. Or they want to take other action such as showing a poster image
instead.
This is of particular interest to Firefox, as we're planning on showing a
prompt to ask the user whether they would like a site to play. If sites want to
determine whether they can autoplay but avoid the prompt showing, they won't be
able to just call play() in Firefox and see whether it works, as that would
likely show the prompt if the user doesn't already have a stored permission.
We've been working out a spec here:
https://github.com/whatwg/html/issues/3617#issuecomment-398613484
This implements what is the consensus to date there;
HTMLMediaElement.allowedToPlay, which returns true when a play() call would not
be blocked with NotAllowedError by autoplay blocking policies.
MozReview-Commit-ID: AkBu0G7uCJ0
Mostly automatic via sed. Only parts which I touched manually (apart from a
couple ones where I fixed indentation or which had mispelled arguments) are the
callers. I may have removed a couple redundant `virtual` keywords as well when
I started to do it manually, I can revert those if wanted.
Most of them are just removing the argument, but in Element.cpp I also added an
assertion for GetBindingParent when binding the ShadowRoot's kids (the binding
parent is set from the ShadowRoot constructor, and I don't think we bind a
shadow tree during unlink or what not which could cause a behavior difference).
Differential Revision: https://phabricator.services.mozilla.com/D2574
MozReview-Commit-ID: 2oIgatty2HU
In our autoplay shield-study, we want to collect the information which could tell us how many website
contains audible autoplay media, but there is no way to get this information on current API desigin.
Therefore, I would like to send a new notification when autoplay occurred.
The extension code could get the information by following way,
```
Services.obs.addObserver((subject, topic, data) => {
// DO SOMETHING
}, "AudibleAutoplayMediaOccurred");
```
MozReview-Commit-ID: 4bSYcxDZOGK
We'd like to add telemetry to help inform the decision as to how enabling
block autoplay will affect video playback in the wild.
Our data science team would also like some input to help them estimate the
rate at which our shield study would receive pings, and the telemetry
collected here will help them estimate that.
We'd like to collect the following, on a per session basis:
* Count of the number of top level content documents loaded, as denominator for
other stats collected here.
* Count of the number of top level content documents which contained (directly
or in a descendant document) playback of an audible media element.
* Count of the number of top level content documents which contained (directly
or in a descendant document) a muted media element that was paused by the
autoplay policy because it tried to unmute and it wasn't allowed to autoplay
audibly.
* Count of the total number of audible autoplay videos that would have not been
allowed to play if block autoplay was enabled. We'd either prompt for
permission on these videos, or block outright depending on user's settings.
* Count of the total number of audible autoplay videos that would have been
allowed to play if block autoplay was enabled.
MozReview-Commit-ID: vHWJPyqHjT
