BindContext was going to have way more information at first, but then I realized
that most of the things I wanted to know were basically a flag away using the
parent node.
Still I think it's worth it, now experimenting with BindToTree will only mean
adding a field to a struct that's included from a couple cpp files, instead of a
massive pain.
I also think this is clearer, and doing this highlights quite a few
inconsistencies in our code which I've left untouched, but commented with
FIXMEs.
Steps are:
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsresult BindToTree(Document\* aDocument, nsIContent\* aParent,#nsresult BindToTree(BindContext\&, nsINode\& aParent)#g' $file; done
$ for file in $(rg 'nsresult BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's# nsIContent\* aBindingParent) override#override#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(Document\* aDocument, nsIContent\* aParent,#::BindToTree(BindContext\& aContext, nsINode\& aParent)#g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#nsIContent\* aBindingParent)##g' $file; done
$ for file in $(rg '::BindToTree\(' | cut -d : -f 1 | sort | uniq); do sed -i 's#::BindToTree(aDocument, aParent, aBindingParent)#::BindToTree(aContext, aParent)#g' $file; done
$ ./mach clang-format
Then manual fixups.
Depends on D32948
Differential Revision: https://phabricator.services.mozilla.com/D32949
$ for file in $(rg UnbindFromTree | cut -d : -f 1 | sort | uniq); do sed -i 's#UnbindFromTree(bool aDeep = true,#UnbindFromTree(#g' $file; done
$ for file in $(rg UnbindFromTree | cut -d : -f 1 | sort | uniq); do sed -i 's#UnbindFromTree(bool aDeep,#UnbindFromTree(#g' $file; done
$ for file in $(rg UnbindFromTree | cut -d : -f 1 | sort | uniq); do sed -i 's#UnbindFromTree(aDeep,#UnbindFromTree(#g' $file; done
$ ./mach clang-format
And fix the two callers and little use of the aDeep argument (see the "Manual
changes" patch attached to bug).
Differential Revision: https://phabricator.services.mozilla.com/D32898
--HG--
extra : moz-landing-system : lando
This patch structurizes the media debug information via webidl dictionaries
that are returned by HTMLMediaElement::GetMozRequestDebugInfo() and
MediaSource::GetMozDebugReaderData().
Differential Revision: https://phabricator.services.mozilla.com/D27893
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
This patch structurizes the media debug information via webidl dictionaries
that are returned by HTMLMediaElement::GetMozRequestDebugInfo() and
MediaSource::GetMozDebugReaderData().
Differential Revision: https://phabricator.services.mozilla.com/D27893
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
This patch moves some `enum` in `nsIPresShell` which are in public scope into
`mozilla` namespace and change them as `enum class`es.
Unfortunately, only "where to scroll" enum is just defines constants of
percentages of scroll destination. Therefore, this patch makes only them
as `static const`.
Differential Revision: https://phabricator.services.mozilla.com/D28606
--HG--
extra : moz-landing-system : lando
This patch adds the number of dropped frames for each step of the process
(read/sink/compositor) and gives us more insight about where frames are
dropped, as opposed to the getVideoPlaybackQuality() API which gives the grand
total.
Differential Revision: https://phabricator.services.mozilla.com/D27488
--HG--
extra : moz-landing-system : lando
The Picture-in-Picture toggle buttons are now part of the video controls UAWidget
bindings, so we need to construct a UAWidget for the no-controls case for Desktop
to make that toggle available.
Up until now, we've never needed a no-controls UAWidget for Desktop, since we
never needed to show UI in that case.
Depends on D26809
Differential Revision: https://phabricator.services.mozilla.com/D26803
--HG--
extra : moz-landing-system : lando
The Picture-in-Picture toggle buttons are now part of the video controls UAWidget
bindings, so we need to construct a UAWidget for the no-controls case for Desktop
to make that toggle available.
Up until now, we've never needed a no-controls UAWidget for Desktop, since we
never needed to show UI in that case.
Differential Revision: https://phabricator.services.mozilla.com/D26803
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
nsIChannel.LOAD_CLASSIFY_URI is no longer required so we can remove it from
the codebase.
In the mean time, we add a new LOAD_BYPASS_URL_CLASSIFIER load flag for
channel creator to be able to force channel to bypass URL classifier check.
The use of the new LOAD_BYPASS_URL_CLASSIFIER flag will be addressed in
the other patches.
Differential Revision: https://phabricator.services.mozilla.com/D22111
--HG--
extra : moz-landing-system : lando
nsIChannel.LOAD_CLASSIFY_URI is no longer required so we can remove it from
the codebase.
In the mean time, we add a new LOAD_BYPASS_URL_CLASSIFIER load flag for
channel creator to be able to force channel to bypass URL classifier check.
The use of the new LOAD_BYPASS_URL_CLASSIFIER flag will be addressed in
the other patches.
Differential Revision: https://phabricator.services.mozilla.com/D22111
--HG--
extra : moz-landing-system : lando
In order to make the implementation more fitting with the spec, move the implementation of `pending-text-track-change-notification-flag` from text track list to media element.
In addition, it also help us not to expose the internal flag `show-poster` (which will be implemented in patch3) of media element when doing the related algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D21810
--HG--
extra : moz-landing-system : lando
In order to make the implementation more fitting with the spec, move the implementation of `pending-text-track-change-notification-flag` from text track list to media element.
In addition, it also help us not to expose the internal flag `show-poster` (which will be implemented in patch3) of media element when doing the related algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D21810
--HG--
extra : moz-landing-system : lando
MediaKeys objects are typically created and associated with an HTMLMediaElement,
however it is possible to create a MediaKeys object and not associate it with an
HTMLMediaElement.
This resulted in an issue where these MediaKeys would keep alive other
components that would assert during bowrser shutdown (see bug 1522547). We
anticipated that MediaKeys associated with an HTMLMediaElement would need to be
shutdown if their owning document became inactive, but were not handling the
case where the keys never became associated with an element.
This patch has the MediaKeys listen directly to their owning document for
activity change. The MediaKeys will shutdown if their document becomes inactive.
This avoids MediaKeys not associated with HTMLMediaElements keeping other
objects alive during browser shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D21983
--HG--
extra : moz-landing-system : lando
In order to display blocking icon when the document comes back from the bfcache, we have to notify front end what's the current blocking status.
As the front end side would clear blocking autoplay information when nagivation occurs, and the media might not invoke the play again when they comes back from the bfcache.
Therefore, we should notify front end side that the site is still being blocked, and we should show blocking icon for it.
Differential Revision: https://phabricator.services.mozilla.com/D21582
--HG--
extra : moz-landing-system : lando
Each instance has an instance of Java ExoPlayer that consumes memory in the
limited JVM heap. Too many concurrent players will cause OutOfMemoryError.
Differential Revision: https://phabricator.services.mozilla.com/D20420
--HG--
extra : moz-landing-system : lando
By adding the Telemetry to measure the number of video/audio which played exactly 7 seconds or more, or less than 7 seconds, after those media has been resumed from blocked state, we can know how many media would meet the Chrome's MEI condition, which could help us to know more about the whole landscape of autoplay media.
In addition, it could help us know how many media are played 'by users intention' because we assume that users are more likely to stop the media if autoplay media is unblocked by accident.
Differential Revision: https://phabricator.services.mozilla.com/D18628
--HG--
extra : moz-landing-system : lando
"blocked" event is used for blocking autoplay. The `AudioChannelAgentBlockedPlay()` returns true when we lost audio focus on Android, so actually we don't need to dispatch "blocked" event.
Differential Revision: https://phabricator.services.mozilla.com/D18627
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
This patch removes the XBL videocontrols binding and make <video>
to always use the UA Widget to generate controls.
DevTools tests that look for NAC is switched to use <input type=file>.
Differential Revision: https://phabricator.services.mozilla.com/D17571
--HG--
extra : moz-landing-system : lando
If media element is used as a source for AudioContext, we would try to start AudioContext which was not allowed
to start when media element starts playing.
Differential Revision: https://phabricator.services.mozilla.com/D14593
--HG--
extra : moz-landing-system : lando
This can legitimately happen while paused since the watchmanager calling this
is dispatching the calls. As such they're out of sync with the paused state,
and we need to allow updating the time while paused.
FireTimeUpdate does ignore the call if the time hasn't actually been updated,
so the only impact from this is that we could do a lot of unnecessary
dispatching while paused without noticing.
Differential Revision: https://phabricator.services.mozilla.com/D15731
--HG--
extra : moz-landing-system : lando
Wrap 'nsContentUtils::ReportToConsole()' to reduce necessary input parameters and call it when we need to log error or warning message. Show the warning when autoplay is blocked.
For web audio, this restores the console messages removed in part4 and also reports the same message when the AudioContext is blocked in the constructor.
Differential Revision: https://phabricator.services.mozilla.com/D14330
--HG--
extra : moz-landing-system : lando
This event is used to notify tab that this site is blocked and we should show the blocking icon for it. Patch2 will handle following details.
Differential Revision: https://phabricator.services.mozilla.com/D14794
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This event is used to notify tab that this site is permanently blocked and we should show the blocking icon for it. Patch2 will handle following details.
Differential Revision: https://phabricator.services.mozilla.com/D14794
--HG--
extra : moz-landing-system : lando
This patch moves all UA Widget calls to helper functions in Element.cpp. The helper function AttachAndSetUAShadowRoot sets the shadow root in a runnable, so that it is in the same order of NotifyUAWidget* runnables.
Differential Revision: https://phabricator.services.mozilla.com/D13479
--HG--
extra : moz-landing-system : lando
Due to the state watcher logic, mirror tasks can be dispatched while in stable state. We must not have visible aJS change during such stable state.
Differential Revision: https://phabricator.services.mozilla.com/D12699
--HG--
extra : moz-landing-system : lando
This removes DecodedStream's use of MediaStreamListener in favor of
MediaStreamTrackListener. This change has however rippled through to a lot
more cleanup, per below.
This moves the MediaStreamTrack lifetime ownership for captured
HTMLMediaElements from the media element to DecodedStream, where the
MediaStreamGraph-side tracks are already created and ended today.
This makes MediaStreamTrack creation explicit across the entire codebase and
lets us remove the MediaStreamTrackSourceGetter class and the infrastructure
of adding MediaStreamTracks after they've already been created in the graph
from DOMMediaStream.
With track ownership, and thus TrackID allocation ownership, happening
exclusively in DecodedStream for its output tracks, we also stop throwing
away and recreating the SourceMediaStream to which we feed data on seek.
This is one step closer to fixing bug 1172394 and spec compliance of
HTMLMediaElement.captureStream().
Differential Revision: https://phabricator.services.mozilla.com/D12273
--HG--
extra : moz-landing-system : lando
HasVideo() might be false even though there is a video track present as it will
only look at the resolution of a VideoTrack.
Differential Revision: https://phabricator.services.mozilla.com/D9103
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Log to the web console when we block autoplay, in order to help web developers debug their sites.
Differential Revision: https://phabricator.services.mozilla.com/D4406
--HG--
extra : moz-landing-system : lando
"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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : rebase_source : b7b17be68dcde00cfeb207cb39cf16b486f2ab02
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
--HG--
extra : rebase_source : f6f8a3facc9d83f5626cf5f3b4e3fa27438a8a8f
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : rebase_source : d6c0dab7a0a2deed0025a0d039ead1f6ad218300
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
--HG--
extra : rebase_source : 81c23390cb603d3fbd284f22b129540a73318d2c
Add new log module which allow us to debug by using "MOZ_LOG=Autoplay:5".
MozReview-Commit-ID: 9CG5JyCw21G
--HG--
extra : rebase_source : c71c4bbed88b07a7803d93b661bfeac37cb94035
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
--HG--
extra : rebase_source : 3f31db79aa1e570fdd9fc7062d0ddac7c96a8931
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
--HG--
extra : rebase_source : 2a4f060dbd582419bf0727408b04f2540155aa02
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
--HG--
extra : rebase_source : e1f22ec83fda8b65d78f1de9f02cf060d424019c
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.
Since we switched to the mp4 rust demuxer, VP9 in mp4 is always supported.
Differential Revision: https://phabricator.services.mozilla.com/D2261
--HG--
extra : moz-landing-system : lando
We can start playing while we're awaiting a response to an autoplay-media
permission prompt, for example if the user clicks on a play button. In such
cases, it doesn't make sense to keep the autoplay permission request promise
connected in HTMLMediaElement, as since we're playing we'll be resolving the
play() promises and thus we won't be taking action on the autoplay request
promise's result. So we should just disconnect the autoplay permission request
promise if it's connected when we start playing.
MozReview-Commit-ID: 1aiCLXV7Ja9
--HG--
extra : rebase_source : c439e8f084ac8cc01db578d712e15d3174a08e71
The front end code can't always guarantee to give us an allow/cancel response
to a permission request. In particular in these cases:
* if we close a tab while showing a doorhanger, or
* if we navigate a tab while showing a doorhanger, or
* if the permission prompt requested in a background tab and never shown.
Handling all of these cases is problematic; we don't get events for all of
these where it's easy and cheap to determine that we should cancel the
permission request.
Canceling the permission request is important in the autoplay-media permission
request case as there's objects waiting on the resolution of the permission
request, and they leak in ASan builds while running chrome tests if the Gecko
size of the permission request doesn't get a notification telling it to stop
waiting.
But we can however rely on the doorhanger code to drop its reference to the
nsIContentPermissionRequest object that we pass to it when the doorhanger goes
away. So we can cancel the permission request in our
nsIContentPermissionRequest's implementation's destructor in order to easily
catch all the above cases.
In order to do that, we need to split AutoplayRequest into two; one part being
the implementation of nsIContentPermissionRequest (AutoplayPermissionRequest),
and the other part being the code to own the PromiseHolder and manage the
permission request (AutoplayPermissionManager).
AutoplayPermissionRequest keeps a weak reference to AutoplayPermissionManager,
so that it can tell the AutoplayPermissionManager to reject the request promise
when it's destroyed.
This fixes the ASan leak for which I got backed out from earlier in this bug,
and also fixes the cases above.
MozReview-Commit-ID: KoVkgIqDleW
--HG--
rename : dom/html/AutoplayRequest.cpp => dom/html/AutoplayPermissionManager.cpp
rename : dom/html/AutoplayRequest.h => dom/html/AutoplayPermissionManager.h
extra : rebase_source : dbca520a93d8c416f6d64c2da027630181bb5910
Test that a video which tries to autoplay via either a play() call or via
an autoplay attribute:
* Plays when it has a pre-existing "allow" autoplay-media permission.
* Is blocked when it has a pre-existing "block" autoplay-media permission.
* Plays when it doesn't have a pre-existing autoplay-media permission and
"allow" is pressed on the door hanger.
* Is blocked when it doesn't have a pre-existing autoplay-media permission and
"block" is pressed on the door hanger.
MozReview-Commit-ID: CpftV6RQbtU
--HG--
extra : rebase_source : a9c38a7e7071e3ebd34f10175f4f22cd84c4c303
When autoplay is requested by setting the "autoplay" attribute, we should
check whether autoplay is allowed in HTMLMediaElement::CheckAutoplayDataReady()
and if not we should prompt for user consent.
This ensures that <video ... autoplay/> will prompt for consent when used on
a page without a pre-existing allow/block permission.
MozReview-Commit-ID: 77pJR2Ybn2i
--HG--
extra : rebase_source : 5cf26822c9e5f23a83d69f5f52c39be6ab6f9eb0
It's possible that if the HTMLMediaElement is loading while we're loading a new
document into a docshell, that the HTMLMediaElement can reach readyState
HAVE_FUTURE_DATA just after its OwnerDoc is removed from the docshell. If the
HTMLMediaElement wasn't paused, then it may start playing due to the readyState
change in HTMLMediaElement::ChangeReadyState().
For years we've had hard to reproduce issues where media started playing after
we've closed the tab; I bet this was the cause!
When we detect that the document has been removed from its DocShell,
HTMLMediaElement::NotifyOwnerDocumentActivityChanged() is called, and that
suspends the MediaDecoder just in case we need to resurrect the media element,
for example if the tab comes out of the BF cache. When we suspend we set
mPausedForInactiveDocumentOrChannel=true, and all other calls to
MediaDecoder::Play() are guarded by checks on
mPausedForInactiveDocumentOrChannel.
So we should also guard the MediaDecoder::Play() call in ChangeReadyState()
with a check on mPausedForInactiveDocumentOrChannel too.
MozReview-Commit-ID: GfmZasT9jdr
--HG--
extra : rebase_source : 5539503795868e9496fe34014b5c04d2ed48241b
extra : source : e94884022fa7df95adf90e44a44e4f168d60f01a
It's possible that if the HTMLMediaElement is loading while we're loading a new
document into a docshell, that the HTMLMediaElement can reach readyState
HAVE_FUTURE_DATA just after its OwnerDoc is removed from the docshell. If the
HTMLMediaElement wasn't paused, then it may start playing due to the readyState
change in HTMLMediaElement::ChangeReadyState().
For years we've had hard to reproduce issues where media started playing after
we've closed the tab; I bet this was the cause!
When we detect that the document has been removed from its DocShell,
HTMLMediaElement::NotifyOwnerDocumentActivityChanged() is called, and that
suspends the MediaDecoder just in case we need to resurrect the media element,
for example if the tab comes out of the BF cache. When we suspend we set
mPausedForInactiveDocumentOrChannel=true, and all other calls to
MediaDecoder::Play() are guarded by checks on
mPausedForInactiveDocumentOrChannel.
So we should also guard the MediaDecoder::Play() call in ChangeReadyState()
with a check on mPausedForInactiveDocumentOrChannel too.
MozReview-Commit-ID: GfmZasT9jdr
--HG--
extra : rebase_source : dba32e8341a3dd70355ccdd7fd8790911a92acc8
extra : source : e94884022fa7df95adf90e44a44e4f168d60f01a
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Sometimes when video is playing, a preroll ad plays, and that may be in a cross
origin iframe. If autoplay media is disabled, we require a user gesture in a
document before playback in that document is permitted, and we require each
origin to be gesture activated separately. So in the cross origin preroll video
add case, then the user will have to click once to unblock playback for the
cross origin ad, and then once the preroll ad finishes, the user will have to
click again to activate playback of the same origin content video.
This is a bad user experience.
So we should instead make gesture activation propagate up the doc tree
irrespective of crossing origins. This way, when the user clicks to activate,
all documents in that tab are also also effectively gesture activated, and so
can autoplay.
MozReview-Commit-ID: 1HZQ5zkubR
--HG--
extra : rebase_source : d6b75732548cb1d73b9f82dce60a5e6e97d1da14
SeekToNextFrame is handled differently than other seeks by the
MediaDecoderStateMachine, and should not take place while other seeks already
are. Bug 1410225 implemented some changes in HTMLMediaElement to prevent this,
but it's still possible to move to a seeking state in the MDSM and accept
SeekToNextFrame (as in this bug).
This changeset changes the MDSM to reject SeekToNextFrame if a seek is already
happening. Since the MDSM now does this the changes from bug 1410225 can be
removed.
This has the functional change of the promise from SeekToNextFrame being
rejected if the seek in not performed due to another seek. Previously the
promise would succeed when the other seek completed. This seems sensible as the
next frame seek does not actually take place.
MozReview-Commit-ID: HD9WRFq3LZV
--HG--
extra : rebase_source : fb276010119038db4319b3b81bcbf51ef2cab1d9
We currently observe changes to HTMLMediaElement::mPaused via a hand-rolled
wrapper class. We can use use mozilla::Watchable<> and avoid rolling our
own equivalent here.
This also paves the way for using state watching on other observable state
in HTMLMediaElement.
MozReview-Commit-ID: 4lBlJiV15iG
--HG--
extra : rebase_source : 22f9d811371f9d609dc96a9d958645e5c634eb17
extra : intermediate-source : bdb8280da440a711c6cd51b65ead7ba9e4bb3597
extra : source : fd8c4b8656a9996eea94d2092caaf3c10fe2a835
We don't need to track this state anymore, as we don't need to delay calling
MediaDecoder::Play() or delay firing the "playing" event anymore.
MozReview-Commit-ID: E3B9l6ep7FP
--HG--
extra : rebase_source : 63df836bf0249ed40b0659cd42794e92966cefb9
I don't think we should allow media without audio tracks to autoplay because:
* It means play() before loaded metadata behaves differently than play()
called after loaded metadata.
* With the current impl we dispatch the "play" event and then the "pause"
event when we decide we should block, which may confuse some sites' controls.
* Delaying running the play() algorithm until we've loaded metadata would add
significant complexity, and may break sites.
* Chrome doesn't have this provision, meaning the complexity required to
support it will not result in much benefit to us.
MozReview-Commit-ID: FSVlDJAOisw
--HG--
extra : rebase_source : 93b1bcf8d8edbd6ca10ad918b40a87cd3cfbbf0b
This patch splits FontTableURI and BlobURL in 2 classes:
FontTableURIProtocolHandler and BlobURLProtocolHandler
both under mozilla::dom.
It also removes a memory reporter because that report is already covered by the
BlobURL one.
--HG--
rename : dom/file/nsHostObjectProtocolHandler.cpp => dom/file/BlobURLProtocolHandler.cpp
rename : dom/file/nsHostObjectProtocolHandler.h => dom/file/BlobURLProtocolHandler.h
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
When using a media element with a Media Source, the resource fetching algorithm is to be called in "local" mode:
https://www.w3.org/TR/media-source/#mediasource-attach
"Continue the resource fetch algorithm by running the remaining "Otherwise (mode is local)" steps, with these clarifications"
https://html.spec.whatwg.org/multipage/media.html#concept-media-load-resource
Under the local mode, the steps that would cause the element to fire suspend, stalled or progress can never occur.
We only prevent the stalled event to be fired, many websites rely on the progress event to be fired (such as when the init segment has been parsed). The HTML5 media spec will be amended to clearly indicate that progress is to be fired even with mediasource
MozReview-Commit-ID: DkoQzoV0JzO
--HG--
extra : rebase_source : 1e916eee50c9935f168797bb5a92052191cda59d
Partially apply clang-format so that we limit the scope of changes while ensuring consistency in declarations.
MozReview-Commit-ID: Km9sKBbFhKx
--HG--
extra : rebase_source : 880e1fc1b46ab57d961e12eb7670260128d0faa1
Currently we can end up dispatching a 'playing' event right before we reject
play() promises, and this confuses YouTube's controls, and it doesn't make
sense to dispatch a 'playing' event when we're not playing anyway.
This is because the logic to delay resolving the play() promise until after
we've reached loadedmetadata doesn't prevent the 'playing' event from being
dispatched. We shouldn't dispatch 'playing' until we resolve the play()
promise(s).
MozReview-Commit-ID: 5H4dcObfu4M
--HG--
extra : rebase_source : b4036a8fead95cd3070f9fc4d30e0feb23d1f64c
We already reject the play promises when we call Pause(), so this extra
reject is unnecessary.
MozReview-Commit-ID: 6LKw7hCwJPH
--HG--
extra : rebase_source : b75c147c2f475cf1ae4b4dddc3085c306f31d6e6
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
We'd like to know the proportion of HTMLMediaElement.play() calls that are
rejected due to autoplay being blocked. There are also other conditions that
cause us to reject the promise returned by HTMLMediaElement.play(), so add
telemetry to report all the identifyable conditions under which play()
succeeds or fails.
MozReview-Commit-ID: AZ67WWXaowN
--HG--
extra : rebase_source : 4a164cb0b4fb7fb6944cd371c6e90dde021a4dc0
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
We want to block playback of media which have an audio track, so if play()
is called before the load of the resource has loaded metadata, we need to
delay starting playback and resolving the play promise until we've figured
out whether the media has audio. So if play() is called before we've reached
readyState >= HAVE_METADATA, set a flag, and check that flag when we do
reach HAVE_METADATA and start the play and resolve the promise then.
MozReview-Commit-ID: 1K06NK2kfpw
--HG--
extra : rebase_source : 45636e77b44ed072e1bc3f1e9a9f73f206ee04de
Our autoplay blocking is trivial to defeat; just mute or volume=0 a video,
play(), and then unmute, and then you're playing audibly.
So this patch makes us pause() media that become audible atfter playback
has started.
MozReview-Commit-ID: 2RAtbohMGJO
--HG--
extra : rebase_source : 021510102374185debc89610bc6027206a0af6fc
To make it easier to tell what HTMLMediaElement API functions sites' JS is
calling, we should add more mozlogs. This will make it easier to figure out why
things aren't playing.
MozReview-Commit-ID: 9eVvkagGNgf
--HG--
extra : rebase_source : 153a68f27ec5c2b17c3c5a9e31d54b98ccc1a1ea
To make it easier to tell what HTMLMediaElement API functions sites' JS is
calling, we should add more mozlogs. This will make it easier to figure out why
things aren't playing.
MozReview-Commit-ID: 9eVvkagGNgf
--HG--
extra : rebase_source : 6f117a036fc5ce10413660fb9fd5d418d74e159d
Previously, in IsInRanges, aIntervalIndex could have values between -1..length-1.
After the change, the values are in range 0..length, which makes it possible to use unsigned ints and avoid UB.
MozReview-Commit-ID: 39SIzXRHv91
--HG--
extra : rebase_source : d0efebb4bc13694eb7d2048cd2eae2d6386238cf
The changes in bug 1324883 regressed YouTube, so back them out.
The changes in bug 1324883 were trying to cause the media cache to be cleared
on tab close and on CTRL+F5 reload (i.e. a bypass cache-reload) but they are
causing problems on YouTube, which doesn't use the media cache and instead
uses MSE.
MozReview-Commit-ID: Hx2cehZ2wm1
--HG--
extra : rebase_source : fa0bd85570746e60341e8e2d3f874f9bd30c0232
Mostly-mechanical additions:
- Log constructions&destructions, usually by just inheriting from
DecoderDoctorLifeLogger, otherwise with explicit log commands (for internal
classes for which DecoderDoctorTraits can't be specialized),
- Log links between most objects, e.g.: Media element -> decoder -> state
machine -> reader -> demuxer -> resource, etc.
And logging some important properties and events (JS events, duration change,
frames being decoded, etc.)
More will be added later on, from just converting MOZ_LOGs, and as needed.
MozReview-Commit-ID: KgNhHSz35t0
--HG--
extra : rebase_source : dd7206e350e32671adc6f3b9e54ebf777251de2c
We calculate 'canplaythrough' in ChannelMediaDecoder::DownloadProgressed() and
send updates to MDSM.
MozReview-Commit-ID: KAeDciPAUKs
--HG--
extra : rebase_source : 64d7705fb5ca6b1003664ac313ad1ae0ab1bbea6
Per UX spec, we would allow non-audible media (volume 0, muted, video without audio track)
to autoplay.
MozReview-Commit-ID: HKUyt5Jt4sH
--HG--
extra : rebase_source : 83e53a0035d72984494948f131a5d6e516baa577
If the media has started playing before, bless it and it would always be allowed
to autoplay.
MozReview-Commit-ID: 4GqMARLXULU
--HG--
extra : rebase_source : 2fdb3937156147755f8e387b1d84311ae1d37ce4
If the media has started playing before, bless it and it would always be allowed
to autoplay.
MozReview-Commit-ID: 28X4TmG25aJ
--HG--
extra : rebase_source : 3fd7cb16da9e7f925ad7020fb74c48537e08a996
The process of |TryRemoveMediaKeysAssociation()| is a 2-step async procedue in mainthread.
mMediaKeys might be set to null inside |NotifyOwnerDocumentActivityChanged()| in between
|TryRemoveMediaKeysAssociation| and |RemoveMediaKeys|.
MozReview-Commit-ID: HtiADt3UTvp
--HG--
extra : rebase_source : 9eff95040b3e900fb778187e4e432bce0b41396b
Per UX spec, we would allow non-audible media (volume 0, muted, video without audio track)
to autoplay.
MozReview-Commit-ID: HKUyt5Jt4sH
--HG--
extra : rebase_source : 97315d90fa46a16289135ac7490bd0dab651d682
This patch is mainly reverting the changing of bug1382574 part3, but not all the same.
Since youtube would call load() when user clicks to play, and then call play()
later. For the old pref (checking user-input-play), we should still allow the
following play() even it's not triggered via user input. It's also same for
seeking, Youtube would call play() after seeking completed.
In this patch, we would allow the script-calling once play() if user has called load()
or seek() before that.
MozReview-Commit-ID: 1UcxRCVfhnR
--HG--
extra : rebase_source : c72212ebf29ea624128a8190dab67e1197f1f198
Per UX spec, we would allow non-audible media (volume 0, muted, video without audio track)
to autoplay.
MozReview-Commit-ID: HKUyt5Jt4sH
--HG--
extra : rebase_source : fa8d1bfd2fb667e974dbe499d7f8215273d4fa10
This is necessary in order to parse style attributes using the subject
principal of the caller, rather than defaulting to the page principal.
MozReview-Commit-ID: GIshajQ28la
--HG--
extra : rebase_source : 5dba46f61d70ec647cae16383b62961ac72d2f47
We won't need to check the whether the media element is interacted with user for
autoplay anymore.
MozReview-Commit-ID: 2tll9LtGyVR
--HG--
extra : rebase_source : 0047f482c2932e7063fc556ce8c306ff276efbfd
AutoplayPolicy is used to manage autoplay logic for all kinds of media,
including MediaElement, Web Audio and Web Speech.
MozReview-Commit-ID: R1TxMkarIw
--HG--
extra : rebase_source : 8c608a1d12c8e205391a91f22e1532bc4f2c8f16
There are currently two types of sinks for a MediaStreamTrackSource.
Actual MediaStreamTracks and HTMLMediaElement::StreamCaptureTrackSource.
A source needs actual tracks as sinks to not stop() the underlying source.
A StreamCaptureTrackSource, however, should not count toward keeping a source
alive (otherwise HTMLMediaElement.mozCaptureStream() would prevent track.stop()
from working on the track feeding the media element).
MozReview-Commit-ID: 9MBAyZFZUIQ
--HG--
extra : rebase_source : a73f182b95281baf4f44f7ae82158e4a6bce42eb
This is a drive-by fix in that it is not directly related to what the bug is
solving. However, making HTMLMediaElement register as a sink is important,
and pairing it with the WeakPtr<Sink> patch reduces risk greatly.
MozReview-Commit-ID: 7pMDw3MG0ZB
--HG--
extra : rebase_source : e2f2b3a12b9921373518d94a083adda23bfe853b
This patch implements HTMLMediaElement::GetEventTargetParent and set
aVisitor.mCanHandle to false to mouse/touch/pointer events, when
the media control is present. This tells the event dispatcher that
these events are supposed to be handled exclusively by the
videocontrol binding within the media element, and should not
dispatch nor consumed by the content.
MozReview-Commit-ID: BXWZX9SYsuC
--HG--
extra : rebase_source : 5d6633a2e1a456d2d619b6f68498065d94c68c40
This patch implements HTMLMediaElement::GetEventTargetParent and set
aVisitor.mCanHandle to false to mouse/touch/pointer events, when
the media control is present. This tells the event dispatcher that
these events are supposed to be handled exclusively by the
videocontrol binding within the media element, and should not
dispatch nor consumed by the content.
MozReview-Commit-ID: BXWZX9SYsuC
--HG--
extra : rebase_source : e9922ac6064c953ee233d6829e84bc7828518b43
The MediaKeys status inside a HTMLME cannot be reflected correctly if the mSetCDMRequest is disconnected in HTMLME::ShutdownDecoder.
This may happen when a page calls load() or sets new src right after setting MediaKeys to null.
MozReview-Commit-ID: 3BZOmw7BNFO
--HG--
extra : rebase_source : f06ae54944133e8e48471e71f0bb8fe46290cca8
1. move all checks to CanActivateAutoplay()
2. don't cache the pref's value in advance, it might cause wrong result
if user changes pref after media was binded to tree.
MozReview-Commit-ID: 3BeOeaq9wGa
--HG--
extra : rebase_source : 74085dce2852d0a608f6455bd0b9337b8223fa20
The return value is unchecked in MediaDecoder, and we only ever returned
NS_OK anyway. And we if the dispatch fails, we can't really do anything;
dispatching an "error" event probably won't work.
MozReview-Commit-ID: 67K6Mjft6tY
--HG--
extra : rebase_source : ad644e8b97fc11488983bc05e18c9941b3c5b062
We queried 'loadingprincipal' attribute on the common call path, however
this should be queried if it's loaded by System Principal.
Also rename loadingprincipal to triggeringprincipal
MDSM doesn't reset the decoding pipeline of MFR when doing NextFrameSeek and
therefore fails the assertion by requesting video data while MFR is still seeking.
We put the fix in the media element because it doesn't make sense to do
NextFrameSeek while another seek is already in action.
MozReview-Commit-ID: D6FSiNWHrLU
--HG--
extra : rebase_source : 7793fa32fb5fe3406f235aa43908a8a96202ee6c
The old code doesn't print readyState changes when networkState is EMPTY.
MozReview-Commit-ID: 8rWUbpsmNuu
--HG--
extra : rebase_source : 509ebf1ae94e2618e63c764ef8fdf0869cb60582
Now DecoderTraits doesn't need to depend on ChannelMediaDecoder.
MozReview-Commit-ID: D4AUiV2eGWy
--HG--
extra : rebase_source : 38e6c4cdd0f7e32473c6945550bca6fd0cc72bf2
See comment 3 for the root cause.
MozReview-Commit-ID: CX5npKv2eWG
--HG--
extra : rebase_source : 085192f55b082f878d2f9915c24e89a56a981799
extra : source : 07f12b6df9d35eb3d215835a174504c70120b588
In order to tailor certain security checks to the caller that is attempting to
load a particular piece of content, we need to be able to attach an
appropriate triggering principal to the corresponding requests. Since most
HTML content is loaded based on attribute values, that means capturing the
subject principal of the caller who sets those attributes, which means making
it available to AfterSetAttr hooks.
MozReview-Commit-ID: BMDL2Uepg0X
--HG--
extra : rebase_source : 25e438c243700a9368c393e40e3a6002d968d6c8
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Also assert readyState is HAVE_NOTHING before creating a new decoder.
MozReview-Commit-ID: B0QACf96AA3
--HG--
extra : amend_source : ef4b41db04ee10f7eaae8f388d984ed0fd0863b5
Also assert readyState is HAVE_NOTHING before creating a new decoder.
MozReview-Commit-ID: B0QACf96AA3
--HG--
extra : rebase_source : f89bd84b130273ff734471619485d5f12a83006d
extra : source : 9b63f9eaa250ebe7259cc7fab709aac00858aaf6
These listeners will be AddRefed/Released off the main thread when
OMT data delivery is enabled.
MozReview-Commit-ID: CSOBgNNf3OW
--HG--
extra : rebase_source : d9085c6447e51d3aa9cad79fa1e25d986fdee792
extra : intermediate-source : 21be6f0003e6d3ccf4448e6574ea5d3122665155
extra : source : 8ce13766af359b5e55524e47ea74bcfc0e0133f8
We register the nsIWebProgressListener at the root docshell(GetSameTypeRootTreeItem) to handle video element embedded in iframe.
MozReview-Commit-ID: D4CavLDAnKD
--HG--
extra : rebase_source : 93032297272bbfc8570dce0c8c13ea9f0d45f7a8
Fix after an observed nullptr deref on try where mOutputStreams contained an
object whose mStream member had been nulled out.
MozReview-Commit-ID: 4kL1choTeW3
--HG--
extra : rebase_source : e4a6f600a66f00a963b19bf74717246c5099a784
MediaStreamGraph only implements the blocking notifications for SourceMediaStreams,
but the MediaStream that gets attached as srcObject on a media element is always
a TrackUnionStream. Hence, this code is unused and can be removed.
MozReview-Commit-ID: 6DKtCGNsZec
--HG--
extra : rebase_source : 0b3b7156a9e2e70933edadcc0a59c8fa81d49913
The extension policy services uses atoms internally for permission names, so
using them directly rather than strings is considerably cheaper.
MozReview-Commit-ID: Io8EuOXHKVy
--HG--
extra : rebase_source : 577b4bdf7f899729e4cf92961a8e9e25bf886a72
1. since setVolume would trigger updateWakelock(), we should set |mOuter| before that.
2. move outer as required parameter in its constructor.
3. should init all member varaibles which would be referenced by wakeLockWrapper before its initialization.
MozReview-Commit-ID: H9A3aCKp6eT
--HG--
extra : rebase_source : 5ba1c78b305cc0db125b43c29bff1389f3e9ddb1
This is required to use nsIThreadRetargetableRequest::RetargetDeliveryTo().
MozReview-Commit-ID: GFuAjovabpY
--HG--
extra : rebase_source : 4fbc7877f2548dcf0777c820ee724f41c46de688
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
No need to prevent sleeping for non-audible audio.
MozReview-Commit-ID: 6p3azSUWTU2
--HG--
extra : rebase_source : 89ff9d1753ac4a23269ec100920e18020ab5aafb
For knowing the wake lock usage more clearly, we should use more specific topic name.
In OSX, you can use "$ pmset -g assertions" to check all the wakelock.
In Windows, using "$ powser -energy" to generate the energy report.
MozReview-Commit-ID: rAXnkxTvLc
--HG--
extra : rebase_source : 42ebf204673d3c913739f64c71c24af20d37c95d
The timer was added for the b2g issue, now we can remove it.
MozReview-Commit-ID: BNjIghImCzC
--HG--
extra : rebase_source : c5490d417b2d40619eb7092dfc21b19a99982a1c
These functions didn't be used by anyone, remove them.
MozReview-Commit-ID: BLj8GsVp1gR
--HG--
extra : rebase_source : 1b7eee86c62314401c2374a2979ba2a42fda2490
If TimeUnits.h includes mozilla/dom/TimeRanges.h, then the build ends up
pulling in the Gecko DOM bindings, which pulls in a whole lot of JavaScript and
DOM bindings code. That makes it trickier to import GeckoMedia into Servo, and
makes Gecko's build slower, so move the code to convert TimeIntervals into
dom::TimeRanges.
Also remove an extraneous "virtual" and add "const" to some functions in TimeRanges.
MozReview-Commit-ID: BLeehaf9gCE
--HG--
extra : rebase_source : 84ef054cf8fd5b4434dc761a1b0a39803d3231f5
According to [1], we should return NotSupportedError for the negative playback rate.
[1] https://github.com/w3c/web-platform-tests/pull/6522
MozReview-Commit-ID: KoqDkBmP3h9
--HG--
extra : rebase_source : ddf1cdd03a980686df6d6613e1bd507bf37d8337
If AddMediaElementToURITable() is called after the decoder Load failed, mDecoder
will be reset and it is sufficient to assert mDecoder only.
MozReview-Commit-ID: 58WT8zFeiFj
--HG--
extra : rebase_source : 712579b544e9a9ce971778b85795d06e58bd4ea5
extra : intermediate-source : 470e2d8a20010e11d7a7dce5540957e89439811e
extra : source : 59f4b2b33212794aa1cf3e8782737a2d4af8c241
This fixes the bug where mWaitingForKey is reset only when mPaused is false.
We should reset mWaitingForKey to NOT_WAITING_FOR_KEY when the key is
available and decoding can continue.
http://w3c.github.io/encrypted-media/#resume-playback
MozReview-Commit-ID: LjIhe9cTsdg
--HG--
extra : rebase_source : d2d351928d1994ee3ae688d4e798ab204ab1609c
extra : intermediate-source : e8700b4344aa29f6b2c52ee4d920d59db4012577
extra : source : 41e1c10f32465ca0abac61bbfd555ee89a8c67a1
Instead, MediaDecoder::NextFrameStatus() checks IsEnded() and returns
NEXT_FRAME_UNAVAILABLE to ensure we have HAVE_CURRENT_DATA when playback
is ended on the main thread.
This will fix the timing issue (comment 0) which causes 'waiting' to fire.
MozReview-Commit-ID: 7O21x2q0lb8
--HG--
extra : rebase_source : bbd898edfb5f4a47a5062dd2bc916c911caf0c8e
extra : intermediate-source : 2b3e413db02a7aad00d13fdf274b346bccafc414
extra : source : 6f60fad11b65e75b456e128f8414fe2ea545455f
This fixes the bug where mWaitingForKey is reset only when mPaused is false.
We should reset mWaitingForKey to NOT_WAITING_FOR_KEY when the key is
available and decoding can continue.
http://w3c.github.io/encrypted-media/#resume-playback
MozReview-Commit-ID: LjIhe9cTsdg
--HG--
extra : rebase_source : 0563bf7831ed66bcdb5bec741b1366243eed49f9
extra : intermediate-source : e8700b4344aa29f6b2c52ee4d920d59db4012577
extra : source : 41e1c10f32465ca0abac61bbfd555ee89a8c67a1
Instead, MediaDecoder::NextFrameStatus() checks IsEnded() and returns
NEXT_FRAME_UNAVAILABLE to ensure we have HAVE_CURRENT_DATA when playback
is ended on the main thread.
This will fix the timing issue (comment 0) which causes 'waiting' to fire.
MozReview-Commit-ID: 7O21x2q0lb8
--HG--
extra : rebase_source : 0a676ef7278214a707c97687311a73da8bcd983e
extra : intermediate-source : 2b3e413db02a7aad00d13fdf274b346bccafc414
extra : source : 6f60fad11b65e75b456e128f8414fe2ea545455f
In bug 1312886, we made sure that readyState would never become HAVE_ENOUGH_DATA if we were waiting for a key.
However, this is in effect useless as the next call to ChangeReadyState would have reset mWaitingForKey.
In practice, it only meant that we delayed the change from HAVE_FUTURE_DATA to HAVE_ENOUGH_DATA until the next call to UpdateReadyState.
MozReview-Commit-ID: 2wnMeN8xxCS
--HG--
extra : rebase_source : f5b0fa50ead1565882c3bf8ba245702987784d8a
By default, a media element that has never played is in paused mode. As such, we need to reset mWaitingForKey to NOT_WAITING_FOR_KEY otherwise, readyState will never become HAVE_ENOUGH_DATA.
MozReview-Commit-ID: EIi3Crt4zHl
--HG--
extra : rebase_source : e9f9ad4136020db7db081b5c125f664e1c7bda20
I noticed that touching MediaDecoder rebuilds a lot of seemingly unrelated
code. This is because HTMLMediaElement includes MediaDecoder.h, and
HTMLMediaElement is included in a number of places. Having HTMLMediaElement.h
predeclare rather than include fixes it.
MozReview-Commit-ID: I0vrPgqvvge
--HG--
extra : rebase_source : 505f9dce979aad0529b07d2c046dca5028af6de6
I noticed that touching MediaDecoder rebuilds a lot of seemingly unrelated
code. This is because HTMLMediaElement includes MediaDecoder.h, and
HTMLMediaElement is included in a number of places. Having HTMLMediaElement.h
predeclare rather than include fixes it.
MozReview-Commit-ID: I0vrPgqvvge
--HG--
extra : rebase_source : 505f9dce979aad0529b07d2c046dca5028af6de6
I noticed that touching MediaDecoder rebuilds a lot of seemingly unrelated
code. This is because HTMLMediaElement includes MediaDecoder.h, and
HTMLMediaElement is included in a number of places. Having HTMLMediaElement.h
predeclare rather than include fixes it.
MozReview-Commit-ID: I0vrPgqvvge
--HG--
extra : rebase_source : 366d4e34e9c425b478b4c9058e27c9a32de36515
1. we move clone related methods to BaseMediaResource which is the only cloneable sub-class of MediaResource.
2. add CanClone() to ChannelMediaDecoder to reduce the dependency on MediaResource for HTMLMediaElement.
MediaResource should be internal details to MediaDecoder.
MozReview-Commit-ID: Hl2nAiuyTO0
--HG--
extra : rebase_source : 43dd9ee33ef2ef2e9093eb6b264dc174379d61d2
extra : source : 978ded48a90f2c407c4545486243acabf492736a
Since we will remove ChannelMediaDecoder from HLSDecoder's base class, we can't
create HLSDecoder in InstantiateDecoder which returns a ChannelMediaDecoder.
MozReview-Commit-ID: 9wcrIVIOZFp
--HG--
extra : rebase_source : cf0e55a6a0eafeb4e34ff1eed5bb7e1d97d73e80
extra : source : edefbf5d7179c5390bd2a25fbbcd025095d39555
