The media element being used in the PIP mode would always display on the screen even if the the tab it belongs to is in the background, so users would have high chance to interact with it again. Therefore, we don't want to start a stop-timer to cancel media control for that element.
Differential Revision: https://phabricator.services.mozilla.com/D67381
--HG--
extra : moz-landing-system : lando
In order to be able to change the audio output device, the device id is exposed to the constructor of MediaStreamGraph. Any component that gets/creates an MTG will be able to provide the device id in order to determine the desired output device. If the provided device id is null the default device will be used.
Differential Revision: https://phabricator.services.mozilla.com/D64133
--HG--
extra : moz-landing-system : lando
Intercepting media control keys would also come up with the virtual control interface in most of platforms, and for the notification sound we don't want either to show the interface or control them.
Currently we use 3s as a threshold to filter those short duration media which are possible to be a notification sound.
Differential Revision: https://phabricator.services.mozilla.com/D64478
--HG--
extra : moz-landing-system : lando
This patch is used to prevent intercepting media keys from other applications which should really receive media keys. For example, if user finishes watching a video but doesn't close that tab, and switch to other tasks. Then if they have other applications which are playing music, when they press media keys, the application which should receive media keys should be those background music app, not Firefox.
Therefore, if the media has been paused for a while, then that might indicate that user won't need to control this media anymore. Therefore, we create a timer, which default expire time is 60s, to stop listening media control key events for those kinds of media. But if the media starts again during this period, we would destroy timer and continue to control that media.
Differential Revision: https://phabricator.services.mozilla.com/D63918
--HG--
extra : moz-landing-system : lando
It's useless to update the audible state before starting listening to the media control keys event, so we make it consistent with other functions which could only be used after starting the listener.
As the audible change could happen before we start the listener, we have to manually update audible state to the controller after we start the listener.
Differential Revision: https://phabricator.services.mozilla.com/D63943
--HG--
extra : moz-landing-system : lando
When media is not audible yet, or it's inaudible at all (maybe it's used as a background video or GIF-like image), or the media is in the tab which has been muted totally, we don't want to use media control to control those media, so we should postpone starting listening to the media control keys for them event until they become audible.
Once they become audible, we would keep control them all the time even if they become inaudible again.
Differential Revision: https://phabricator.services.mozilla.com/D63915
--HG--
extra : moz-landing-system : lando
Those suspend and resume related logic were used for implemeting media control and audio focus on Fennec. After removing those things, the only purpose of `AudioChannelAgentCallback` would be muting and unmuting media element from audio channel (eg. clicking sound indicator to mute/unmute tab)
Differential Revision: https://phabricator.services.mozilla.com/D65264
--HG--
extra : moz-landing-system : lando
This attribute is used to expose the internal suspend state of media element to see if we set `SUSPENDED_PAUSE` and `SUSPENDED_PAUSE_DISPOSABLE` correctly. As we don't use those suspend state anymore and have removed the related tests, no need to keep this attribute anymore.
Differential Revision: https://phabricator.services.mozilla.com/D65263
--HG--
extra : moz-landing-system : lando
`media-playback-resumed` was a notification we used on Fennec to indicate media playback state changes and we should update the UI button on the virtual control interface. As it's not being used by anyone since we deprecate Fennec, we can remove all related code.
Differential Revision: https://phabricator.services.mozilla.com/D65258
--HG--
extra : moz-landing-system : lando
At the time CC unlink happens, we would no longer need to listen to the media control key events. Therefore, we should remember to stop and clear the listener to avoid its any method ran after CC.
Differential Revision: https://phabricator.services.mozilla.com/D64787
--HG--
extra : moz-landing-system : lando
This covers most cycle collected objects which support weak references, but
not the ones which inherit from a cycle collected class and don't do any cycle
collection on their own.
Differential Revision: https://phabricator.services.mozilla.com/D63962
--HG--
extra : moz-landing-system : lando
The check here was used to prevent calling play or pause during playing or pausing.
However, according to the spec [1], even if media session is playing, we would still want to trigger its play action handler when play action happens. So we should forward all media control key events to the content, not to block any of them.
[1] https://w3c.github.io/mediasession/#handle-media-session-action
Differential Revision: https://phabricator.services.mozilla.com/D60918
--HG--
extra : moz-landing-system : lando
When media element is inactive, asking MDSM to seek is actually useless, because all the data we decode won't be showed to user. In addition, we have to store extra pending events for `seeking` and `seeked`, which might result in memory overflow if the inactive page is calling `seek()` all the time.
Therfore, we should delay all seeking tasks while media is inactive, and perform the latest seeking task when media becomes active.
Differential Revision: https://phabricator.services.mozilla.com/D58918
--HG--
extra : moz-landing-system : lando
Two parameters in `SuspendOrResumeElement()` are acutally the same, they are both related with `IsActive()`, so using one parameter is enough.
In addition, we only suspend or resume element by checking element's active state, so rename `mPausedForInactiveDocumentOrChannel` to `mSuspendedForInactiveDocument` which fits the actual situation more.
Differential Revision: https://phabricator.services.mozilla.com/D58749
--HG--
extra : moz-landing-system : lando
Modify IPC method to support notify `ControlledMediaState` to the media controller, and remove the previous implementation.
Differential Revision: https://phabricator.services.mozilla.com/D57572
--HG--
extra : moz-landing-system : lando
We create `MediaControlEventListener` to register itself to the `MediaControlAgent` that is an event source, so that we can receive the media control event from the evnet source and operate media according to different types of event.
`MediaControlEventListener` is also used to notify controlled media state to the media controller. When media first starts playing, or leaves bfcache and has created listener before, we would notify `eStarted`. Notify `eStopped` when media destroys, or enter bfcache and has created listener before. When media's playing state changes, we would notifty `ePlayed` or `ePaused` depeding on media's `mPaused`.
Differential Revision: https://phabricator.services.mozilla.com/D57571
--HG--
extra : moz-landing-system : lando
This patch is used to change the blessed state for media element under `click-to-play` blocking autoplay policy, which only allows play invocation called from user input handler, eg. `onclick`.
When media aborts current load, we should regard it as a new media. One example is on Youtube they always reuse same media element but replace its url for different video. Therefore, we should reset media's blessed state so that the media with new url can be blocked again.
Differential Revision: https://phabricator.services.mozilla.com/D57192
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
For media element, as the spec requires that we should know the whether it can be allowed to play when we call `media.play()` [1], which means that we should get the result before the play invocation.
Therefore, we request for the play permission when we create media element.
Differential Revision: https://phabricator.services.mozilla.com/D52438
--HG--
extra : moz-landing-system : lando
Move helper functions out from `AutoplayPolicy`, makes us clearly know which one could really be used to determine the blocking autoplay result. It also give other classes an ability to use those helper functions if they have a need.
Differential Revision: https://phabricator.services.mozilla.com/D52432
--HG--
extra : moz-landing-system : lando
For media element, as the spec requires that we should know the whether it can be allowed to play when we call `media.play()` [1], which means that we should get the result before the play invocation.
Therefore, we request for the play permission when we create media element.
Differential Revision: https://phabricator.services.mozilla.com/D52438
--HG--
extra : moz-landing-system : lando
Move helper functions out from `AutoplayPolicy`, makes us clearly know which one could really be used to determine the blocking autoplay result. It also give other classes an ability to use those helper functions if they have a need.
Differential Revision: https://phabricator.services.mozilla.com/D52432
--HG--
extra : moz-landing-system : lando
Unlink of mSrcStream used to rely on EndSrcMediaStreamPlayback to unhook
everything. That method does more than necessary however, and if anything in it
creates a strong reference to the media element, we risk a leak.
This patch takes what's necessary to unhook from EndSrcMediaStreamPlayback and
runs it explicitly from Unlink, to avoid anything unnecessary being run as well.
Differential Revision: https://phabricator.services.mozilla.com/D51906
--HG--
extra : moz-landing-system : lando
Unlink of mSrcStream used to rely on EndSrcMediaStreamPlayback to unhook
everything. That method does more than necessary however, and if anything in it
creates a strong reference to the media element, we risk a leak.
This patch takes what's necessary to unhook from EndSrcMediaStreamPlayback and
runs it explicitly from Unlink, to avoid anything unnecessary being run as well.
Differential Revision: https://phabricator.services.mozilla.com/D51906
--HG--
extra : moz-landing-system : lando
It is no longer needed with captured tracks' lifetimes spanning across seek
operations.
Differential Revision: https://phabricator.services.mozilla.com/D52051
--HG--
extra : moz-landing-system : lando
This reworks how media element captureStream works by removing the differences
between MediaStream and MediaDecoder capture. MediaDecoder capture will be
refactored so that ownership of MediaStreamTracks lies with the media element
instead of the OutputStreamManager. The internal MediaDecoder parts happen in a
later patch.
The new API for capturing a MediaDecoder involves a boolean on/off toggle, the
output tracks the decoder pipes data to, and the principal that data is tagged
with. If capturing is on but there are no output tracks, playback will not
happen, to ensure that no data gets accidentally skipped in the output tracks
while captured.
This also changes the logic for setting up MediaElementTrackSources in
HTMLMediaElement so it's triggered by the WatchManager and thus run in tail
dispatched runnables.
Differential Revision: https://phabricator.services.mozilla.com/D52040
--HG--
extra : moz-landing-system : lando
It is no longer needed with captured tracks' lifetimes spanning across seek
operations.
Differential Revision: https://phabricator.services.mozilla.com/D52051
--HG--
extra : moz-landing-system : lando
This reworks how media element captureStream works by removing the differences
between MediaStream and MediaDecoder capture. MediaDecoder capture will be
refactored so that ownership of MediaStreamTracks lies with the media element
instead of the OutputStreamManager. The internal MediaDecoder parts happen in a
later patch.
The new API for capturing a MediaDecoder involves a boolean on/off toggle, the
output tracks the decoder pipes data to, and the principal that data is tagged
with. If capturing is on but there are no output tracks, playback will not
happen, to ensure that no data gets accidentally skipped in the output tracks
while captured.
This also changes the logic for setting up MediaElementTrackSources in
HTMLMediaElement so it's triggered by the WatchManager and thus run in tail
dispatched runnables.
Differential Revision: https://phabricator.services.mozilla.com/D52040
--HG--
extra : moz-landing-system : lando
This is especially important for media elements playing MediaStreams, since the
streams can be manipulated to end playback of the elements synchronously by
either stopping or removing their tracks.
Differential Revision: https://phabricator.services.mozilla.com/D49385
--HG--
extra : moz-landing-system : lando
It started progressing as soon as we set up the rendering of the tracks in the
stream, which is too early according to the HTMLMediaElement spec.
Now it starts progressing when we're potentially playing. The difference being
that we now wait for mReadyState to go beyond HAVE_CURRENT_DATA before hooking
up the time progression mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D49354
--HG--
extra : moz-landing-system : lando
This makes all inputs to IsPotentiallyPlayin() Watchable when we're playing a
MediaStream.
Differential Revision: https://phabricator.services.mozilla.com/D49353
--HG--
extra : moz-landing-system : lando
Everytime when we start a controller, we should also update its audible state correctly, in order to request audio focus correctly.
Differential Revision: https://phabricator.services.mozilla.com/D50151
--HG--
extra : moz-landing-system : lando
It can be unset by NotifyShutdown, to release the VideoFrameContainer in time.
This is unexpected for all paths assuming it will be unset by
EndSrcMediaStreamPlayback().
Depends on D49573
Differential Revision: https://phabricator.services.mozilla.com/D49574
--HG--
extra : moz-landing-system : lando
This change mainly removes the `mTracks` member from MediaStream and moves all
associated members up a level, so that a MediaStream in practice represents a
single track.
Classes will be renamed in a future patch to reflect this.
Other changes include:
The new `mEnded` member of MediaStream changes meaning to only become true when
all data in the stream has been processed. It stems from
StreamTracks::Track::mEnded which used to become true as soon as the last bit of
data had been added to a track, and there could still be data in the track that
would get processed in future iterations. We are moving towards not having any
future data in tracks, which is why this change is ok to make -- keeping the old
behavior will soon not make sense.
TrackUnionStream is changed to no longer take a list of streams as input and
forward the union of their tracks to itself. Instead it's limited to having one
track as input at a time.
The autofinishing functionality that TrackUnionStream had before has been
transformed into an autoending functionality to allow it to defer ending until
its been told that it's ok to end through the control API. This lets a single
TrackUnionStream span the lifetime of multiple inputs, which will be useful for
making DecodedStream spec compliant with HTMLMediaElement::CaptureStream(), and
for implementing the currently discussed MediaRecorder::ReplaceTrack(), to name
a few potential use cases.
AudioNodeStreams used to only have a track (and thus an AudioSegment) if the
EXTERNAL_OUTPUT flag was enabled on them. With all MediaStreams now representing
a track, AudioNodeStreams inherently have an AudioSegment as a member. It is
however only used with data if the EXTERNAL_OUTPUT flag is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D45821
--HG--
extra : moz-landing-system : lando
This functionality is not used since we moved to only having a single track per
MediaStream (bug 1493613).
Differential Revision: https://phabricator.services.mozilla.com/D47686
--HG--
extra : moz-landing-system : lando
This change mainly removes the `mTracks` member from MediaStream and moves all
associated members up a level, so that a MediaStream in practice represents a
single track.
Classes will be renamed in a future patch to reflect this.
Other changes include:
The new `mEnded` member of MediaStream changes meaning to only become true when
all data in the stream has been processed. It stems from
StreamTracks::Track::mEnded which used to become true as soon as the last bit of
data had been added to a track, and there could still be data in the track that
would get processed in future iterations. We are moving towards not having any
future data in tracks, which is why this change is ok to make -- keeping the old
behavior will soon not make sense.
TrackUnionStream is changed to no longer take a list of streams as input and
forward the union of their tracks to itself. Instead it's limited to having one
track as input at a time.
The autofinishing functionality that TrackUnionStream had before has been
transformed into an autoending functionality to allow it to defer ending until
its been told that it's ok to end through the control API. This lets a single
TrackUnionStream span the lifetime of multiple inputs, which will be useful for
making DecodedStream spec compliant with HTMLMediaElement::CaptureStream(), and
for implementing the currently discussed MediaRecorder::ReplaceTrack(), to name
a few potential use cases.
AudioNodeStreams used to only have a track (and thus an AudioSegment) if the
EXTERNAL_OUTPUT flag was enabled on them. With all MediaStreams now representing
a track, AudioNodeStreams inherently have an AudioSegment as a member. It is
however only used with data if the EXTERNAL_OUTPUT flag is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D45821
--HG--
extra : moz-landing-system : lando
This functionality is not used since we moved to only having a single track per
MediaStream (bug 1493613).
Differential Revision: https://phabricator.services.mozilla.com/D47686
--HG--
extra : moz-landing-system : lando
The request is used to track if the promise is resolved or not, so we should call its `Complete()` method once promise is resolved, in order to keep the state of the request correct.
Differential Revision: https://phabricator.services.mozilla.com/D47331
--HG--
extra : moz-landing-system : lando
In bug1583978, we are going to remove `AudibleState::eMaybeAudible`. But before that, as `AudibleState::eMaybeAudible` is only used for delaying media playback, so we can remove its usage from media element and move it to the dedicated class to reduce confusion about how and when we should use `AudibleState::eMaybeAudible` or `AudibleState::eNotAudible`.
Differential Revision: https://phabricator.services.mozilla.com/D47153
--HG--
extra : moz-landing-system : lando
Now `AudioChannelWrapper` would only start `AudioChannelAgent` when media starts and stop the agent when media stops. It won't handle any case with `SUSPENDED_BLOCK`.
It's clearer to know when we would start or stop the agent in AudioChannelWrapper.
In addition, in bug1577890, we will remove more unnecessary logic which is used for Fennec only in order to make `AudioChannelWrapper` cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D44747
--HG--
extra : moz-landing-system : lando
Separate the logic of delaying media playback from `HTMLMediaElement`'s `mAudioChannelWrapper` to a new class, because delaying media playback is a special usage of using `AudioChannelAgent`.
It would make the code cleaner and separate the normal usage and the special usage, to reduce confusion.
We usually start `AudioChannelAgent` when media playback starts and stop it when media playback stops, however, in this case, we would start the agent even if media hasn't be started yet, because we would like to use the agent as a connection with `AudioChannelService` in order to receive the resume command when we're able to play delayed playback.
Differential Revision: https://phabricator.services.mozilla.com/D44746
--HG--
extra : moz-landing-system : lando
As we have another usage to know whether media is audible or not, we remove this function from AudioChannelWrapper and make it as media element's function.
In addition, it also makes sense to have this function for media element, because the result is decided by media element's own attributes.
Differential Revision: https://phabricator.services.mozilla.com/D44744
--HG--
extra : moz-landing-system : lando
There are some checking conditions can be reordered or simplified in order to remove some unnecessary check.
Differential Revision: https://phabricator.services.mozilla.com/D47027
--HG--
extra : moz-landing-system : lando
After applying patch4, now we would pull the change from `AudioChannelService` everytime after starting the agent, so we don't need to rely on letting `NotifyStartedPlaying()` to modify the config and use it to update our state.
Differential Revision: https://phabricator.services.mozilla.com/D45753
--HG--
extra : moz-landing-system : lando
As we start audio capturing explicitly, we should also take responsibility to stop audio capturing when we don't need it.
We were hiding too many details on `AudioChannelAgent` before, which allow us hard to know who and where we handle audio capturing.
Differential Revision: https://phabricator.services.mozilla.com/D45752
--HG--
extra : moz-landing-system : lando
Instead of calling those callback functions seperately, we could provide a function to pull those changes at once after starting the agent.
In addition, `WindowXXXChanged` are callback functions of `nsIAudioChannelAgentCallback`, so they should only be called by `AudioChannelAgent`, to indicate receiving the change from `AudioChannelService`. We should not call them directly.
Differential Revision: https://phabricator.services.mozilla.com/D45751
--HG--
extra : moz-landing-system : lando
We have already had the same checking in `AudioCaptureStreamChange()`, so we can remove the checking in `AudioCaptureStreamChangeIfNeeded()`.
Differential Revision: https://phabricator.services.mozilla.com/D45749
--HG--
extra : moz-landing-system : lando
After applying patch4, now we would pull the change from `AudioChannelService` everytime after starting the agent, so we don't need to rely on letting `NotifyStartedPlaying()` to modify the config and use it to update our state.
Differential Revision: https://phabricator.services.mozilla.com/D45753
--HG--
extra : moz-landing-system : lando
As we start audio capturing explicitly, we should also take responsibility to stop audio capturing when we don't need it.
We were hiding too many details on `AudioChannelAgent` before, which allow us hard to know who and where we handle audio capturing.
Differential Revision: https://phabricator.services.mozilla.com/D45752
--HG--
extra : moz-landing-system : lando
Instead of calling those callback functions seperately, we could provide a function to pull those changes at once after starting the agent.
In addition, `WindowXXXChanged` are callback functions of `nsIAudioChannelAgentCallback`, so they should only be called by `AudioChannelAgent`, to indicate receiving the change from `AudioChannelService`. We should not call them directly.
Differential Revision: https://phabricator.services.mozilla.com/D45751
--HG--
extra : moz-landing-system : lando
We have already had the same checking in `AudioCaptureStreamChange()`, so we can remove the checking in `AudioCaptureStreamChangeIfNeeded()`.
Differential Revision: https://phabricator.services.mozilla.com/D45749
--HG--
extra : moz-landing-system : lando
People keep adding useless null-checks and it was not clear what the consensus
was from bug 1441165, but this should be unobjectionable I guess.
Differential Revision: https://phabricator.services.mozilla.com/D46781
--HG--
extra : moz-landing-system : lando
Tasks dispatched from RunInStableState() can be cancelled if there's a load in
between, so this is not sound.
See nsSyncSection::IsCancelled().
This is the only patch in this bug that is worth uplifting IMO.
Differential Revision: https://phabricator.services.mozilla.com/D46773
--HG--
extra : moz-landing-system : lando
We use `NotifyMediaStarted()` and `NotifyMediaStopped()` to notify `MediaControlService` on parent process to start/stop a media controller, and use `NotifyMediaAudibleChanged()` to notify controller's audible state in order to request audio focus.
As our goal is to use media controller to control media element, not for web audio, web speech and other stuffs which also use audio channel agent.
Therefore, we should notify parent process to start/stop controller only for media element, instead of sending a notification in AudioChannelService because that would create media controller for all different consumers which uses audio channel agent.
Differential Revision: https://phabricator.services.mozilla.com/D45591
--HG--
extra : moz-landing-system : lando
Spliting NotifyAudioChannelAgent() to StartAudioChannelAgent() and StopAudioChanelAgent() allows us to start and stop an AudioChannelAgent in a clear naming function, and to do related operation and checking every time we start/stop the agent.
Differential Revision: https://phabricator.services.mozilla.com/D45590
--HG--
extra : moz-landing-system : lando
Only SeekToNextFrame cares about promises, but prior to this patch the common
method HTMLMediaElement::Seek() would always return a promise.
When the caller was not SeekToNextFrame (e.g., SetCurrentTime, FastSeek), the
promise would end up *not* being exposed. When later rejected, we would catch
this and write an error to the js console.
This patch lifts the handling of the promise out of Seek() and into
SeekToNextFrame() so that we avoid creating promises that would not get exposed
to js.
Differential Revision: https://phabricator.services.mozilla.com/D42511
--HG--
extra : moz-landing-system : lando
Only SeekToNextFrame cares about promises, but prior to this patch the common
method HTMLMediaElement::Seek() would always return a promise.
When the caller was not SeekToNextFrame (e.g., SetCurrentTime, FastSeek), the
promise would end up *not* being exposed. When later rejected, we would catch
this and write an error to the js console.
This patch lifts the handling of the promise out of Seek() and into
SeekToNextFrame() so that we avoid creating promises that would not get exposed
to js.
Differential Revision: https://phabricator.services.mozilla.com/D42511
--HG--
extra : moz-landing-system : lando
This fixes an edge case where it was possible for an HTMLMediaElement in the
middle of setup to have ownership transferred to a inactive document and deref a
null pointer. This happened because we have special handling for EME related
media where we perform more aggressive shutdown on for media in inactive
documents.
As far as I can tell, there's nothing specced that forbids performing EME
related functionality on elements in inactive documents. However, our code
already prevents doing so in other cases. E.g. if you create an inactive
document, place an HTMLMediaElement in it and try to setup EME related data on
it, then that will fail. So this fix just covers another such case.
While it would be nice to support doing these operations on inactive document's
media, it seems like very much an edge case, and something that would require a
large amount of reworking in how we handle inactive documents. We can cross that
bridge later should we ever need do so.
Differential Revision: https://phabricator.services.mozilla.com/D40482
--HG--
extra : moz-landing-system : lando
This fixes an edge case where it was possible for an HTMLMediaElement in the
middle of setup to have ownership transferred to a inactive document and deref a
null pointer. This happened because we have special handling for EME related
media where we perform more aggressive shutdown on for media in inactive
documents.
As far as I can tell, there's nothing specced that forbids performing EME
related functionality on elements in inactive documents. However, our code
already prevents doing so in other cases. E.g. if you create an inactive
document, place an HTMLMediaElement in it and try to setup EME related data on
it, then that will fail. So this fix just covers another such case.
While it would be nice to support doing these operations on inactive document's
media, it seems like very much an edge case, and something that would require a
large amount of reworking in how we handle inactive documents. We can cross that
bridge later should we ever need do so.
Differential Revision: https://phabricator.services.mozilla.com/D40482
--HG--
extra : moz-landing-system : lando
This removes all telemetry which expired in Firefox 69 or earlier, with the
exceptions of the following, which we plan to renew:
* AUDIO_TRACK_SILENCE_PROPORTION
* MEDIA_AUTOPLAY_WOULD_BE_ALLOWED_COUNT
* MEDIA_AUTOPLAY_WOULD_NOT_BE_ALLOWED_COUNT
* MEDIACACHESTREAM_LENGTH_KB
* MEDIA_MKV_CANPLAY_REQUESTED
* MEDIA_PAGE_COUNT
* MEDIA_PAGE_HAD_MEDIA_COUNT
* VIDEO_DROPPED_FRAMES_PROPORTION
* VIDEO_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME_PERCENTAGE
* VIDEO_INFERRED_DECODE_SUSPEND_PERCENTAGE
* VIDEO_INTER_KEYFRAME_AVERAGE_MS
* VIDEO_INTER_KEYFRAME_MAX_MS
* VIDEO_SUSPEND_RECOVERY_TIME_MS
* VIDEO_VP9_BENCHMARK_FPS
* WEB_AUDIO_BECOMES_AUDIBLE_TIME
* WEBVTT_TRACK_KINDS
Differential Revision: https://phabricator.services.mozilla.com/D37313
--HG--
extra : moz-landing-system : lando
This removes all telemetry which expired in Firefox 69 or earlier, with the
exceptions of the following, which we plan to renew:
* AUDIO_TRACK_SILENCE_PROPORTION
* MEDIA_AUTOPLAY_WOULD_BE_ALLOWED_COUNT
* MEDIA_AUTOPLAY_WOULD_NOT_BE_ALLOWED_COUNT
* MEDIACACHESTREAM_LENGTH_KB
* MEDIA_MKV_CANPLAY_REQUESTED
* MEDIA_PAGE_COUNT
* MEDIA_PAGE_HAD_MEDIA_COUNT
* VIDEO_DROPPED_FRAMES_PROPORTION
* VIDEO_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME_PERCENTAGE
* VIDEO_INFERRED_DECODE_SUSPEND_PERCENTAGE
* VIDEO_INTER_KEYFRAME_AVERAGE_MS
* VIDEO_INTER_KEYFRAME_MAX_MS
* VIDEO_SUSPEND_RECOVERY_TIME_MS
* VIDEO_VP9_BENCHMARK_FPS
* WEB_AUDIO_BECOMES_AUDIBLE_TIME
* WEBVTT_TRACK_KINDS
Differential Revision: https://phabricator.services.mozilla.com/D37313
--HG--
extra : moz-landing-system : lando
This is inherently large, because modifying these bits of DOMMediaStream and
MediaStreamTrack affects all consumers and producers of all DOMMediaStreams and
MediaStreamTracks.
Things are generally much simpler now.
Producers of tracks now create a MediaStream in the graph, add it to a
MediaStreamTrackSource subclass that takes ownership of it, and add the source
to a MediaStreamTrack. Should the producer need a DOMMediaStream it is now much
simpler to create as the only thing needed is the current window. The stream is
a rather simple wrapper around an array of MediaStreamTracks.
HTMLMediaElement is still not as straight forward as other consumers since it
consumes the DOMMediaStream directly, as opposed to a set of tracks.
The new MediaStreamRenderer helper class helps bridge the gap between this fact
and the new track-based MediaStreamGraph interface, as it needs to juggle
registering multiple audio tracks for audio output. This hooks into existing
HTMLMediaElement logic and brings a welcome simplification to all the glue
previously needed there.
Differential Revision: https://phabricator.services.mozilla.com/D37934
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
This also removes the following prefs, because they're unused:
- media.autoplay.allow-muted pref
- media.autoplay.blackList-override-default
Differential Revision: https://phabricator.services.mozilla.com/D36396
--HG--
extra : rebase_source : 0570540496302b3efedadf4d5115ee5422d5c279
The spec allows non-integer values, but we don't have a good way to store them
in nsAttrValue yet. See https://bugzilla.mozilla.org/show_bug.cgi?id=1561440
HTMLTableCellElement::MapAttributesIntoRule can now call
MapImageSizeAttributesInto instead of manually mapping width and height, because
0 values (which it was excluding before) are now excluded at attribute parse
time.
For 'width' on HTMLTableElement I kept our old behavior for 0, which matches the spec
but not Safari or Chrome.
For 'height' on HTMLTableElement I kept our old behavior for 0, which matches
Safari and Chrome but not the spec. https://github.com/whatwg/html/issues/4715
tracks a possible spec change.
Same thing for 'height' on HTMLTableRowElement.
Same thing for 'width' on HTMLTableColElement.
The ParseImageAttribute call in HTMLMediaElement is not needed, because
HTMLAudioElement does not map any of those to style and HTMLVideoElement only
maps width/height, which it already parses.
Differential Revision: https://phabricator.services.mozilla.com/D36127
--HG--
extra : moz-landing-system : lando
This was done as a catch-all in PlaybackEnded(), but playback might not end if
the source changes in the middle of playback. This catches those cases too.
Differential Revision: https://phabricator.services.mozilla.com/D35321
--HG--
extra : moz-landing-system : lando
HTMLMediaElement::mUnboundFromTree was added in bug 1239899, and I'm pretty
sure its behaviour is intended to be the same as what IsInComposedDocument()
gives us, so we can just use that instead.
Differential Revision: https://phabricator.services.mozilla.com/D35295
--HG--
extra : moz-landing-system : lando
Video tracks are not added to output streams that capture only audio, so we
cannot assume that an output stream that captures only audio has been locked to
capture MediaStream sources when a video track is removed.
Depends on D34854
Differential Revision: https://phabricator.services.mozilla.com/D34855
--HG--
extra : moz-landing-system : lando
This FireTimeUpdate(false) dates back to bug 611994. Perhaps it was spec
compliant back in the day, but it surely isn't now.
Differential Revision: https://phabricator.services.mozilla.com/D33651
--HG--
extra : moz-landing-system : lando
Bug 1279865 introduced this under the premise of
"Run TimeMarchesOn() at the beginning of play.", but it did a bit too much.
This makes us spec compliant for this particular case again.
Differential Revision: https://phabricator.services.mozilla.com/D33650
--HG--
extra : moz-landing-system : lando
HTMLMediaElement::CanActivateAutoplay() had an exception for MediaStreams in its
check for whether autoplay can be activated. This removes that exception and
requires us to be in HAVE_ENOUGH_DATA regardless of source, per spec.
Doing this broke autoplay of an ended media element that's playing a
MediaStream, since autoplay of this MediaStream could no longer be immediately
activated. The exact sequence algorithm for autoplaying the stream in this case
is not defined in mediacapture-main, but we know we must reach HAVE_ENOUGH_DATA
to play, and we must run the load algorithm to reach HAVE_ENOUGH_DATA, that's
what we do:
When the MediaStream we're autoplaying once again becomes active, we run the
media element load algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D33298
--HG--
extra : moz-landing-system : lando
Unsetting a playing video element's MediaStream-srcObject attribute will
otherwise leave the element displaying the latest frame of the video track.
Differential Revision: https://phabricator.services.mozilla.com/D33295
--HG--
extra : moz-landing-system : lando
This allows it to intercept frames in the rendering pipe, so that we don't have
to duplicate the logic for converting VideoChunks to NonOwningImages.
Differential Revision: https://phabricator.services.mozilla.com/D33292
--HG--
extra : moz-landing-system : lando
Also, in many place, we use document uri as referrer. It is not right
for the case srdoc iframe. We should use the last non-srdoc parent
document's uri
Differential Revision: https://phabricator.services.mozilla.com/D30191
--HG--
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-data.html
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-srcdoc.html
extra : moz-landing-system : lando
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
