All the other expressions are anchored via ^ and $.
MozReview-Commit-ID: BkCbZZUnwK6
--HG--
extra : rebase_source : 0dc6c7577898e447946217494e5cd491b13e22fa
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
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
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