When a tab is backgrounded, or on some platforms, when the window is
fully covered, full decoding of a video for playback is disabled. The
video timeline still advances, but there are no valid frames for
presentation. Similarly, if an HTMLVideoElement is in the DOM tree but
marked as invisible (e.g. 'display: none;' is set), we also cease full
decoding of a video. This is the VideoDecodeMode::Suspend mode.
Chrome and Safari both continue to honour requestVideoFrameCallback when
the video element is invisible in a foreground tab. Conversely, when we
are in a backgrounded tab, Chrome suspends rVFC callbacks, while Safari
continues.
Given that we suspend requestAnimationFrame callbacks similar to Chrome
for backgrounded tabs, this patch matches our behaviour with Chrome.
The standard does not discuss the implications of visibility and
background/foreground on rVFC. We have filed an issue requesting for
clarification, and that can tracked at:
https://github.com/WICG/video-rvfc/issues/92
Differential Revision: https://phabricator.services.mozilla.com/D220274
In bug 1883435 comment 2 chutten mentions that including
nsGlobalWindowInner.h from GleanMetrics.h causes a stylo build failure.
This is because nsGlobalWindowInner.h itself brings a bunch of DOM
bindings template soup that bindgen isn't great at dealing with.
That can be fixed in various ways. However, there is a simpler fix,
which is not including GleanMetrics at all.
It's trivial to do, and given it's a massive autogenerated file, and
Document.h is a very common header, it's worth doing this if only for
build times.
Fix a bunch of unused includes while at it.
Differential Revision: https://phabricator.services.mozilla.com/D203625
Much like BindToTree.
This will be useful because I need to pass more information through
UnbindFromTree() to speed up dir=auto for bug 1874040.
Differential Revision: https://phabricator.services.mozilla.com/D202215
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
This was added for bug 1659060 and bug 1679314, but it is effectively
superseded by bug 1755748, which makes document.hidden false if PiP is
used.
Covered by toolkit/content/tests/browser/browser_media_wakelock_PIP.js
Differential Revision: https://phabricator.services.mozilla.com/D189940
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
VideoFrameContainer already knows a frame's intrinsic size. The same intrinsic
size that drives media element invalidation.
ImageContainer just handles images and they don't have a notion of intrinsic
dimensions.
Differential Revision: https://phabricator.services.mozilla.com/D174085
This means there is significantly less chance of desynchronization between the
actual size of the image and the reported size of the image.
Differential Revision: https://phabricator.services.mozilla.com/D149150
This means there is significantly less chance of desynchronization between the
actual size of the image and the reported size of the image.
Differential Revision: https://phabricator.services.mozilla.com/D149150
In this patch, we move the responsibility of accumulating time and report the telemetry to `TelemetryProbesReporter`.
There are some differences between new telemetry report and the old one.
1. more accuracy on knowing if element is visible
2. more accuracy on determining when it should start accumulating visible & invisible play time
3. being able to report the correct result when element encounts an error or changes to a new resource
4. report result whenever MediaDecoder stops working
Here is the explanation [1] describing why our previous method was not able to achieve those advantages.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1685399#c13
Differential Revision: https://phabricator.services.mozilla.com/D101112
When a tab is in the background, its document visibility would become invisible even if a tab owns a video which is visible because of being used in picture in picture mode.
When a document changes its visibility, the wakelock would change its lockstate from `lock-foreground` to `lock-background`. For `video-playing` wakelock topic, we would only request a real platform lock for `lock-foreground` because we don't want to prevent screen from sleeping if the video is invisible.
Therefore, considering if video is being used in picture in picture mode, when determining the wakelock's visible state. If video is still being used in picture in picture mode, then we would treat wakelock as if it's in foreground in order to keep a screen lock.
Differential Revision: https://phabricator.services.mozilla.com/D90781
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 unclutters HTMLMediaElement somewhat by putting away the logic for handling
the FirstFrameListener into MediaStreamRenderer, which is better suited for the
task.
This will allow us to use a second MediaStreamRenderer to properly track video
tracks for a secondary VideoFrameContainer.
Differential Revision: https://phabricator.services.mozilla.com/D87134
Andrew Osmond