It is called from MediaSourceDecoder::SetMediaSourceDuration() which asserts !IsShutdown().
MozReview-Commit-ID: LF8rRPZhkA2
--HG--
extra : rebase_source : 886778f70d00e8670a203e9d322e442c9d117a72
1. It is called from SetInitialDuration() when mMediaSource is non-null which happens before Shutdown() which clears |mMediaSource|.
2. It is called from MediaSource::SetDuration() which happens before MediaSourceDecoder::Shutdown() for |mDecoder| is non-null.
3. It is called from MediaSource::DurationChange() where |mDecoder| is non-null.
MozReview-Commit-ID: 56AmWRLkkiv
--HG--
extra : rebase_source : 1f9443ac3670b12401ffa5ad397638c095e72566
1. It is called from OnSeekResolved() which asserts !IsShutdown().
2. It is called from UpdateLogicalPosition which asserts !IsShutdown().
MozReview-Commit-ID: J8iuHdUamLS
--HG--
extra : rebase_source : 97215383aa7c409f8b63f5a6726b81df53252227
1. Callbacks from the watch manager are disconnected in Shutdown().
2. It is called from MediaOmxCommonDecoder::NotifyOffloadPlayerPositionChanged() which will not happen after Shutdown().
3. It is called from MediaOmxCommonDecoder::ResumeStateMachine() which returns early when IsShutdown() is true.
MozReview-Commit-ID: COmPFaQzNTq
--HG--
extra : rebase_source : ac88698c66f4586b00fe62ad4dcdbb1cb4ce8542
The spec requires the MediaKeyStatusMap.get(keyId) function to return an 'any'
type, which is undefined for known keys, or a MediaKeyStatus enum value for
known keys.
https://w3c.github.io/encrypted-media/#idl-def-mediakeystatusmap
MozReview-Commit-ID: 3TOFYLacZSc
--HG--
extra : rebase_source : cd067f545cdbd9352ba64fea914128201b458d9c
1. It is called from DormantTimerExpired(). The timer is canceled in Shutdown().
2. It is called from NotifyOwnerActivityChanged() which happens before Shutdown().
3. It is called from Play() which happens before Shutdown().
4. It is called from Seek() which happens before Shutdown().
MozReview-Commit-ID: EnKHF61FBXf
--HG--
extra : rebase_source : 04df59b6722c8340e5163a00eb916442799cfcf1
We don't need to check IsShutdown() which is a subset of |mPlayState != PLAY_STATE_PAUSED && !IsEnded()|.
MozReview-Commit-ID: BjYoLOLuPfC
--HG--
extra : rebase_source : 0d04b30a8bf955faed4907f77f0da29e0ccc011d
1. It is called from DurationChanged() which returns early when IsShutdown() is true.
2. It is called from Play() when IsEnded() is true.
MozReview-Commit-ID: Ixy5OMZHxIm
--HG--
extra : rebase_source : 4cd7229084c6af8b7123ee6c85156ef4932308f3
1. It is called from ChangeState() when IsEnded() is true.
2. It is called from OnMetadataUpdate(). The callback is disconnected in Shutdown().
MozReview-Commit-ID: 8m4jtcl91hT
--HG--
extra : rebase_source : 0988128ec6d05f07ab7b072cc70a9c2970c829c5
1. Pause() is called from HTMLMediaElement and happens before Shutdown().
2. Pause() is called from SetPlaybackRate() which is called from HTMLMediaElement.
MozReview-Commit-ID: DDr7Bg8jkF2
--HG--
extra : rebase_source : 8b8a4fdc914d0bce7572d9a1ccb0f530bdba062c
FireTimeUpdate() is only called from UpdateLogicalPositionInternal() which returns early when IsShutdown() is true.
MozReview-Commit-ID: 4GZwrI85aXj
--HG--
extra : rebase_source : 9d7cbd571fd794369c833723ea5fc50a26380e51
1. ConstructMediaTracks() is called from ChangeState() when |mPlayState == PLAY_STATE_PLAYING|.
2. ConstructMediaTracks() is called from MetadataLoaded() which asserts |!IsShutdown()|.
MozReview-Commit-ID: 6OaPYcCOCii
--HG--
extra : rebase_source : 9db9e841fe8a0d797a39cd527abf4f4e95b67131
We want the maximum scroll position to be aligned with layer pixels. That way
we don't have to re-rasterize the scrolled contents once scrolling hits the
edge of the scrollable area.
Here's how we determine the maximum scroll position: We get the scroll port
rect, snapped to layer pixels. Then we get the scrolled rect and also snap
that to layer pixels. The maximum scroll position is set to the difference
between right/bottom edges of these rectangles.
Now the scrollable area is computed by adding this maximum scroll position
to the unsnapped scroll port size.
The underlying idea here is: Pretend we have overflow:visible so that the
scrolled contents start at (0, 0) relative to the scroll port and spill over
the scroll port edges. When these contents are rendered, their rendering is
snapped to layer pixels. We want those exact pixels to be accessible by
scrolling.
This way of computing the snapped scrollable area ensures that, if you scroll
to the maximum scroll position, the right/bottom edges of the rendered
scrolled contents line up exactly with the right/bottom edges of the scroll
port. The scrolled contents are neither cut off nor are they moved too far.
(This is something that no other browser engine gets completely right, see the
testcase in bug 1012752.)
There are also a few disadvantages to this solution. We snap to layer pixels,
and the size of a layer pixel can depend on the zoom level, the document
resolution, the current screen's scale factor, and CSS transforms. The snap
origin is the position of the reference frame. So a change to any of these
things can influence the scrollable area and the maximum scroll position.
This patch does not make us adjust the current scroll position in the event
that the maximum scroll position changes such that the current scroll position
would be out of range, unless there's a reflow of the scrolled contents. This
means that we can sometimes render a slightly inconsistent state where the
current scroll position exceeds the maximum scroll position. We can fix this
once it turns out to be a problem; I doubt that it will be a problem because
none of the other browsers seems to prevent this problem either.
The size of the scrollable area is exposed through the DOM properties
scrollWidth and scrollHeight. At the moment, these are integer properties, so
their value is rounded to the nearest CSS pixel. Before this patch, the
returned value would always be within 0.5 CSS pixels of the value that layout
computed for the content's scrollable overflow based on the CSS styles of the
contents.
Now that scrollWidth and scrollHeight also depend on pixel snapping, their
values can deviate by up to one layer pixel from what the page might expect
based on the styles of the contents. This change requires a few changes to
existing tests.
The fact that scrollWidth and scrollHeight can change based on the position of
the scrollable element and the zoom level / resolution may surprise some web
pages. However, this also seems to happen in Edge. Edge seems to always round
scrollWidth and scrollHeight upwards, possibly to their equivalent of layout
device pixels.
MozReview-Commit-ID: 3LFV7Lio4tG
--HG--
extra : rebase_source : 3e4e0b60493397e61283aa1d7fd93d7c197dec29
extra : source : d43c2d5e87f31ff47d7f3ada66c3f5f27cef84a9
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
Remove string comparisons to determine from mime types if content is VPX or
H264. Replace with calls to VPXDecoder::IsVPX or MP4Decoder::IsH264 to
centralise such logic.
This patch introduces MP4Decoder:IsH264, and moves the similar functionality out
of H264Convertor for the sake of consistently having these functions in
decoders.
MozReview-Commit-ID: 5nfYusYHrUR
--HG--
extra : rebase_source : c013c4ebe28d5afedbb91ddfffadb40d23fd0ee3
After a video has been playing while hidden for a certain time, count the time
until it is not hidden anymore (or it has finished playing), to test-drive how
much decoding time would have been saved by the video-decode-suspend feature.
Note that this is done inside HTMLMediaElement by simulating what should happen
in the MDSM, because instrumenting the MDSM itself and friends would have been
harder and more intrusive.
MozReview-Commit-ID: LdxhPtmoXeA
--HG--
extra : rebase_source : c4063d7c39b56e62e4f397bc21ef889ed14307c8
Previously the tests would check if playback had started by looking at the first
recorded time, and then looking at the current time. If there were a lag it was
possible for the first recorded time to be at the end of the video (i.e.
playback already finished), in which case the video playing would not register.
This patch instead uses the played ranges from the video element. Now so long as
there is a non-empty played range we trust playback started.
MozReview-Commit-ID: 5C39A42KRdj
--HG--
extra : rebase_source : e4e8a35df3bac4c9e7765272acb6300b44b45d4e
GetFirstFrameInRange() uses AdjustTextRectNode() which may return different node before retrieving the result frame. Therefore, the caller may need offset in the new node.
MozReview-Commit-ID: 2AQU5WfahT9
--HG--
extra : rebase_source : c753d34dc2691da2ec25c9f5a6fe17d67af24a70
We need to update mLastComputedValue while processing events that occur at the
same time rather than just skipping over them.
MozReview-Commit-ID: LuxSK6PHFHv
--HG--
extra : rebase_source : be323da2a50ea32838aef322267115d153a14c3d
After a video has been playing while hidden for a certain time, count the time
until it is not hidden anymore (or it has finished playing), to test-drive how
much decoding time would have been saved by the video-decode-suspend feature.
Note that this is done inside HTMLMediaElement by simulating what should happen
in the MDSM, because instrumenting the MDSM itself and friends would have been
harder and more intrusive.
MozReview-Commit-ID: LdxhPtmoXeA
--HG--
extra : rebase_source : 151e1f1383ab5c445eb8c957be8363340cdc4ab1
This behaviour changed as part of Bug 1279493, and the tests should be updated
to reflect this.
MozReview-Commit-ID: oITf0hVjKk
--HG--
extra : rebase_source : 26f54e0ac49a2f27f364c75a63851df5a85ce18f
I also added more testing around ClearKey's base64 decoding, since that affected
how keyIds were handled.
MozReview-Commit-ID: 2UH1JNT4NC3
--HG--
extra : rebase_source : 8e2c861e6b030d7e4a1378d3fafed7630324d940
Returning empty rects for eQueryTextRectArray causes each dispatcher needing to check every rect. It doesn't make sense especially compared with eQueryTextRect.
So, it should ensure that empty rect won't be returned to dispatchers.
MozReview-Commit-ID: CpMqqihzSDf
--HG--
extra : rebase_source : 0343e2eecf5e25043d260157cf4d8b0874e0ceb6
This implements the spec change in 21de090dac
The spec change refers to a binary 'animation direction' flag. Instead of that,
however, we just pass the playback rate along and use it inside
GetComputedTimingAt since this seems simpler.
Also, this patch moves the implementation of
KeyframeEffectReadOnly::GetComputedTiming from the header file into the .cpp
file. This is because with this change, GetComputedTiming needs to call
mAnimation->PlaybackRate() and so mozilla::dom::Animation needs to be a complete
type. However, simply including Animation.h doesn't work because of a cyclic
dependency between KeyframeEffect.h and Animation.h. We might be able to fix
this later but since yet-to-land bug 1049975 moves this code around a lot, I'd
rather not touch it too much just now.
MozReview-Commit-ID: 1h6XRh4xmfI
So, we have 4 boolean variables and here is the truth table.
Case 1, 2, 3, 4, 7, 8, 10 and 12 are not possible to happen.
Then, the remaining cases could be clustered into three categories:
(1) Case 5, 9 and 13: no sample is demuxed at all, return 0.
(2) Case 6, 11, 14 and 15: either audio or video is able to be demuxed, return the known value.
(3) Case 15: both audio and video are demuxed, return the minimum of the values.
For simplifying the logic, I will initialize the audioStartTime and videoStartTime
to be INFINITY if we don't have the first-demuxed sample, otherwise, initialize
them to be the real first-demuxed sample's time.
Then, the final calculation will be:
(1) Case 5, 9 and 13: the minimum of two INFINITY values is still INFINITY, return 0.
(2) Case 6, 11, 14 and 15: return the minimum of one real first-demuxed-time and the INFINITY.
(3) Case 15: return the minimum of two real first-demuxed-time values.
Case HasAudio HasVideo HasAudioSample HasVideoSample ExpectedResult
---------------------------------------------------------------------------------------------------
1 F F F F not possible
2 F F F T not possible
3 F F T F not possible
4 F F T T not possible
---------------------------------------------------------------------------------------------------
5 F T F F return 0
6 F T F T return video sample
7 F T T F not possible
8 F T T T not possible
---------------------------------------------------------------------------------------------------
9 T F F F return 0
10 T F F T not possible
11 T F T F return audio sample
12 T F T T not possible
---------------------------------------------------------------------------------------------------
13 T T F F return 0
14 T T F T return videoSample
15 T T T F return audioSample
16 T T T T return min(auidoSample, videoSample)
MozReview-Commit-ID: ANsYDth7slJ
--HG--
extra : transplant_source : %DAj%1A%EC%19%82%7B%B3%05%FE%21%04a%16%9A%9F%18x1%95
There are various differences between the new ogg player and the old OggReader that leads to inconsistencies on how durations are reported.
1- The old OggReader only use the end time as duration of the video, ignoring the start time of the first sample. This leads to incorrect duration calculation.
2- The OggReader do not ignore undecodable frames located at the beginning of the video, and those are used by the MDSM to calculate the start time. This leads to durations sometimes being shorter than they ought to.
MozReview-Commit-ID: 6yi1P4N6tPE
--HG--
extra : rebase_source : 93e678aa762519d27444a57f8a12d2bd569b025d
We can seek in cached data, we will rely on the seek operation to fail instead to determine if we can't or not
MozReview-Commit-ID: 3Ac7c1nTZTH
--HG--
extra : rebase_source : 569fc9dab9b50b416d29ffc902facf302845755b
The OggReader always passed a complete ogg_packet to the vorbis decoder, ensuring that the right number of frames was be returned. In the conversion to the new architecture, this information got lost making the vorbis decoder always return more frames than normal on the last packet.
MozReview-Commit-ID: HYHxqXfYntJ
--HG--
extra : rebase_source : 3d2a59b011ec1e996ab7aaf29e16baa495f7d31c
This is not the cleanest approach, but ensures identical behavior with the OggReader when it comes to firing loadedmetadata event and handling the change of seekability.
A more universal solution could be considered involving the MediaFormatReader and changing the MediaDataDemuxer API, of interest would be adding support for a new event fired whenever we have a change of content or metadata (useful with MSE or recorded webm of a WebRTC session
MozReview-Commit-ID: BojB2r1CtA3
--HG--
extra : rebase_source : 352fa61b62316264d1a2c8669f427d75f15ca19b
Update handling of VP8, VP9 to enable decryption and decoding via widevine.
Update handling with further validation to make sure that invalid video types
are rejected when trying to create widevine decryptor session or init widevine
decoders.
MozReview-Commit-ID: 8FOvUJfxr6L
--HG--
extra : rebase_source : 0f6aed8256d7f106a598b09e6f11efe80f0e4bb2
In nsGlobalWindow, we have a static counter for how many popups we've seen
recently. We increment it and decrement it when popups open and close - although
the decrement only occurs once the DocShell is detached, which happens asynchronously.
The test uses a utility that returns Promises for window.open and window.close,
but it uses dom-window-destroyed for resolving close, which happens _before_ the
counter is decremented. The dom-window-destroyed observer queues a runnable which
resolves the Promise.
This means that the test is attempting to open windows before the windows from a
previous test have finished detaching their DocShells (and decrementing the counter),
which means that the attempts to open the window hit the popup limit, which blocks
the popups.
This test switches us to waiting for outer-window-destroyed instead, which gives us
a greater certainty that the decrement has occurred.
MozReview-Commit-ID: 3a7QzxelP0a
There were two issues:
1) The keys/entries/values/forEach properties were being added no matater what
the value of the 'unforgeable' boolean was. So we ended up spitting out
unforgeable versions of those, and this confused some Xray cases.
2) The number of args listed for forEach was wrong, which hit assertions in the
JS engine because the same self-hosted function was being instantiated with
different numbers of args from different places.
1. It is called from DormantTimerExpired(). The timer is canceled in Shutdown().
2. It is called from NotifyOwnerActivityChanged() which happens before Shutdown().
3. It is called from Play() which happens before Shutdown().
4. It is called from Seek() which happens before Shutdown().
MozReview-Commit-ID: EnKHF61FBXf
--HG--
extra : rebase_source : 04df59b6722c8340e5163a00eb916442799cfcf1
We don't need to check IsShutdown() which is a subset of |mPlayState != PLAY_STATE_PAUSED && !IsEnded()|.
MozReview-Commit-ID: BjYoLOLuPfC
--HG--
extra : rebase_source : 0d04b30a8bf955faed4907f77f0da29e0ccc011d
1. It is called from DurationChanged() which returns early when IsShutdown() is true.
2. It is called from Play() when IsEnded() is true.
MozReview-Commit-ID: Ixy5OMZHxIm
--HG--
extra : rebase_source : 4cd7229084c6af8b7123ee6c85156ef4932308f3
1. It is called from ChangeState() when IsEnded() is true.
2. It is called from OnMetadataUpdate(). The callback is disconnected in Shutdown().
MozReview-Commit-ID: 8m4jtcl91hT
--HG--
extra : rebase_source : 0988128ec6d05f07ab7b072cc70a9c2970c829c5
1. Pause() is called from HTMLMediaElement and happens before Shutdown().
2. Pause() is called from SetPlaybackRate() which is called from HTMLMediaElement.
MozReview-Commit-ID: DDr7Bg8jkF2
--HG--
extra : rebase_source : 8b8a4fdc914d0bce7572d9a1ccb0f530bdba062c
FireTimeUpdate() is only called from UpdateLogicalPositionInternal() which returns early when IsShutdown() is true.
MozReview-Commit-ID: 4GZwrI85aXj
--HG--
extra : rebase_source : 9d7cbd571fd794369c833723ea5fc50a26380e51
1. ConstructMediaTracks() is called from ChangeState() when |mPlayState == PLAY_STATE_PLAYING|.
2. ConstructMediaTracks() is called from MetadataLoaded() which asserts |!IsShutdown()|.
MozReview-Commit-ID: 6OaPYcCOCii
--HG--
extra : rebase_source : 9db9e841fe8a0d797a39cd527abf4f4e95b67131
Notify audible-changing when resuming audio by MediaElement::play() instead of control interface.
MozReview-Commit-ID: 10a1npQ46Th
--HG--
extra : rebase_source : 16cce6782a132a2aab4ad66dc216d6237fc2ba9f
In practice I'm pretty sure these cases wouldn't have a content docshell anyway.
We probably don't need more robust machinery here, since eventually we'll just
make stylo pref-based for every new prescontext regardless of type.
Use the new FrameStatistics members to report telemetry about inter-keyframe
timings.
MozReview-Commit-ID: 1ZWU2qpSWyC
--HG--
extra : rebase_source : f13fffc2bc81ad6090c3f494cc99e1d198f3256d
FrameStatisticsData can now store inter-keyframe information, which is
provided by the MediaFormatReader (based on live decoding).
MozReview-Commit-ID: HhBy6pgT6ZX
--HG--
extra : rebase_source : 6a072623e8a5b0f23b81307e8ea4b19a3e21b252
HTMLVideoElement can expose its thread-safe FrameStatistics object, so that
HTMLMediaElement can access more adequate data for its telemetry, without
having to use an intermediary (and potentially less accurate)
VideoPlaybackQuality object.
This will also help with accessing other/new FrameStatistics members later on.
MozReview-Commit-ID: AT7mEGy0zGr
--HG--
extra : rebase_source : 35bf6673cc0acd9d4e6e1a58c573749689614d43
Decoders now use FrameStatisticsData to gather data for their frame-related
notifications. This will ease introducing new members later on.
MozReview-Commit-ID: DWdOSPX3JM
--HG--
extra : rebase_source : a3e05f34353a397d1c82b3f4d935c0864f90556e
Decoders uses 64-bit values to count frames, so we should use the same type
in FrameStatistics.
Because VideoPlaybackQuality can only use 32 bits (as defined in W3C specs),
we need to ensure that imported FrameStatistics numbers can fit in 32 bits,
while keeping their ratios the same.
MozReview-Commit-ID: 3pUTGK0ekGv
--HG--
extra : rebase_source : 627fada111b51b8830fd38bf6d60a79b899ce603
Move FrameStatistics' data into separate struct, so that it can more easily be
changed and passed around, outside of the lock-controlled FrameStatistics
object.
MozReview-Commit-ID: TfsMRJhVfQ
--HG--
extra : rebase_source : 8c4c6a23c8c2d6ff4272f9f918c9510326691148
If the mathml.disabled preference is true, treat <math> and other MathML
elements as generic XML elements.
This patch disables the rendering code of MathML however preserves the
namespace so to reduce the breakage.
Original patch by: Kathy Brade <brade@pearlcrescent.com>
MozReview-Commit-ID: A2f2Q2b4eqR
--HG--
extra : rebase_source : 63bf465fa6ff62610d7ed16002a7d479b87df393
When failing to create an audio stream, we fallback to a SystemClockDriver
marked as being a "fallback driver". When failing again to open an audio stream
after re-trying, we can check whether we came from a fallback driver, and not
report the failure again to telemetry.
MozReview-Commit-ID: FAdQ0pCtC3m
Given that Blink has removed prefixed PointerLock API for quite a while
without receiving compatibility issue, I'd suggest we try dropping the
prefixed version directly.
We will either pref the prefixed API on if we see enough compatibility
issue, or remove the whole bunch of prefixed PointerLock API after the
unprefixed API reaches release channel without issues.
MozReview-Commit-ID: ACC69nqSBiH
--HG--
extra : source : 22791c53b6a94c3de4eb7f38823afce89b0419e4
Unfortunately couldn't add all the debug checks that I'd want, since we can't
assert that is not safe to run script in quite a few places :(
MozReview-Commit-ID: 8m3Wm1WntZs
Carsten "Tomcat" Book
Masayuki Nakano
JW Wang
Andrew Comminos
Jan-Ivar Bruaroey
Chris Pearce
Matt Woodrow
Michael Layzell
Eugen Sawin
David Anderson
Terrence Cole
Decky Coss
Thomas Wisniewski
Shih-Chiang Chien
Ethan Lin
Markus Stange
Jeff Gilbert
Nils Ohlmeier [:drno]
Nathan Froyd
Benoit Girard
Bryce Van Dyk
Iris Hsiao
Gerald Squelart
Gregory Szorc
Anthony Jones
Dan Minor
Alastor Wu
Sebastian Hengst
Henrik Skupin
cku
Ben Tian
dimi
Brian Birtles
Nicholas Nethercote
Randall Barker
Tom Schuster
Kaku Kuo
John Dai
Andrew McCreight
Jessica Jong
JerryShih
James Willcox
Rob Wu
Jonathan Kingston
Samael Wang
Stone Shih
Wes Kocher
Eric Rahm
Olli Pettay
Alexander Surkov
André Bargull
Hector Zhao
Jean-Yves Avenard
Mark Banner
Mike Conley
Boris Zbarsky
Bobby Holley
Christoph Kerschbaumer
Reuben Morais
Ben Kelly
James Andreou
Edgar Chen
Marcos Caceres
Nicolas Silva
Lee Salzman
Brad Lassey
Cervantes Yu
Paul Adenot
Daniel Holbert
Tim Taubert
Xidorn Quan
Chris Peterson
Chih-Yi Leu
James Cheng
bechen
Geoff Brown
Emilio Cobos Álvarez
Kyle Machulis
Jonathan Chan