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.
The ogg file contains a theora video track with a flac audio track, not vorbis.
The new OggDemuxer properly ignore the tracks it knows nothing about.
This will cause the tests to use MP4 with h264/aac instead which isn't available on Windows XP, so we mark those tests are expected to fail.
MozReview-Commit-ID: 4UowUS6rQt3
--HG--
extra : rebase_source : d9f8fdde85fa5884d82c5ba612cc5ccf6c57e50f
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
