This re-uses MediaStreamRenderer to render video into a secondary container, to
get identical logic for the clone target as for the clone source. The
MediaStreamRenderer can handle audio, currentTime and more as well, but those
are not used here.
Differential Revision: https://phabricator.services.mozilla.com/D87139
This patch does the following:
- Makes cloneElementVisually() return a promise
- Plumbs an event from the MediaDecoderStateMachine's VideoSink to
HTMLVideoElement
- Hooks the event up to resolve the promise from cloneElementVisually()
- Updates tests and their expectations.
Differential Revision: https://phabricator.services.mozilla.com/D53831
--HG--
extra : moz-landing-system : lando
This patch does the following:
- Makes cloneElementVisually() return a promise
- Plumbs an event from the MediaDecoderStateMachine's VideoSink to
HTMLVideoElement
- Hooks the event up to resolve the promise from cloneElementVisually()
- Updates tests and their expectations.
Differential Revision: https://phabricator.services.mozilla.com/D53831
--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
It mostly works out, because we return an int32_t then just cast it to uint32_t,
but it would be better to return the right thing to start with.
Differential Revision: https://phabricator.services.mozilla.com/D36129
--HG--
extra : moz-landing-system : lando
$ 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
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.
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 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
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
(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
Wakelock would automatically handle the lock/unlock by listening "hidden/visible", we
don't need to handle it in HTMLVideoElement.
MozReview-Commit-ID: AcOwR2nqm6L
--HG--
extra : rebase_source : 8f96b8cd908332be33ed3289dd288990da56c1c9
These functions didn't be used by anyone, remove them.
MozReview-Commit-ID: BLj8GsVp1gR
--HG--
extra : rebase_source : 1b7eee86c62314401c2374a2979ba2a42fda2490
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
This patch makes the media statistics report values with a fixed frames per second
and a dynamic dropped ratio when resistance fingerprinting is enabled. The dropped
rate is decided by the video resolution that it will report a fixed dropped rate
when the video resolution is greater than 480p. And It will report a zero dropped
rate if the video is below or equal to 480p. In addition, it adds three new prefs
that allow us to change the value of frames per second, the dropped ratio and the
threshold of target video resolution. The three prefs are
'privacy.resistFingerprinting.video_frames_per_sec', 'privacy.resistFingerprinting.video_dropped_ratio'
and 'privacy.resistFingerprinting.target_video_res'. The default values of them
are 30, 5 and 480, which means 30 frames per second, 5 percent dropped ratio and
480p.
This also adds a new helper function 'nsContentUtils::ShouldResistFingerprinting(nsIDocument* aDoc)'
for checking whether fingerprinting resistance is enabled for a given docuemnt.
If it is a chrome document, this function will indicate that fingerprinting
resistance is not enabled regardless of the pref 'privacy.resistFingerprinting'.
If it is a content document, the result will depend on the pref.
MozReview-Commit-ID: FbSuRq6Zdnn
--HG--
extra : rebase_source : a62a1be19d9b38520f9eed7164fb258e3354d228
Currently, attribute and child arrays (implemented in dom/base/nsAttrAndChildArray.h) start out empty. When cloning, the array ends up being resized multiple times in order to add the attributes and children that are being cloned from the original node. This would be quicker if the array was initialized to the correct size in the first place so that resizes are not necessary.
However, preallocating space for children is only necessary when performing a deep clone. Therefore, an additional parameter is being added to the Clone, CopyInnerTo, and CloneDocHelper methods to indicate whether preallocation of children should happen. Attributes are copied either way, so that part of the array is preallocated in both cases.
MozReview-Commit-ID: 3iVezeAKXnI
--HG--
extra : rebase_source : 9c3deec6d7aafd6411044d623d4863637b45fd58
Ting-Yu Lin
Andreas Pehrson
Timothy Gu
Daniel Varga
Mike Conley
Nicholas Nethercote
Boris Zbarsky
Peter Van der Beken
Emilio Cobos Álvarez
Csoregi Natalia
Matt Woodrow
Cosmin Sabou
Dorel Luca
Ciure Andrei
Sylvestre Ledru
alwu
Nathan Froyd
Kyle Machulis
Kris Maglione
John Lin
Chris Pearce
Carsten "Tomcat" Book
Phil Ringnalda
Tim Huang
Kirk Steuber