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
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
Daniel Varga
Edgar Chen
Karl Tomlinson
alwu
Micah Tigley
Andreas Pehrson
Csoregi Natalia
Coroiu Cristina
Bryce Seager van Dyk
Narcis Beleuzu
Dan Minor
arthur.iakab
Kannan Vijayan
Nicholas Nethercote
Boris Zbarsky
Chris Pearce
Peter Van der Beken
Thomas Nguyen
Andrea Marchesini
Emilio Cobos Álvarez
Tarek Ziadé
shindli
Andreea Pavel
Noemi Erli
Masayuki Nakano
Ciure Andrei
Paul Adenot
Mike Conley
Sylvestre Ledru
dlee
Gurzau Raul
Brindusan Cristian
Jonathan Kingston
John Lin
Ryan Hunt
Dorel Luca
Christoph Kerschbaumer
Timothy Guan-tin Chien
Ehsan Akhgari
Bogdan Tara
Jean-Yves Avenard
Cosmin Sabou
Alexander Surkov
Alex Chronopoulos
Jan-Ivar Bruaroey