The seeking attribute is changed synchronously, however, the seeking event is fired asynchronously. It is possible that by the time the seeking event is fired, the seeking operation has already completed and that the "time marches on", causing currentTime to be past the seeking position.
MozReview-Commit-ID: IB83w6zKCLF
--HG--
extra : rebase_source : 524519b526b04a4b13a4531f5460c2fbe57f218a
The test should pass now, we do not need different expected results file.
MozReview-Commit-ID: Cl3GBRx1ISN
--HG--
extra : rebase_source : 59a90e20ada254b2a4c65bca34b21cde58a11b0c
It is invalid to assume that no other actions can be performed between the time setTimout is called with a timeout value of 0 and the task actually runs.
This causes events to be regularly missed.
MozReview-Commit-ID: 70dtFsTwETf
--HG--
extra : rebase_source : 15ee481266ec1c8a0db10ee70cc44eefbd8129c5
This doesn't include tests for this behavior, because I'm not sure there's a
good way to test it reliably.
MozReview-Commit-ID: CM5rj1f9YiG
--HG--
extra : rebase_source : 11608a2d0b78802021a4f8aec39f0caa2f75af2c
Calling NotifyDataArrived from each sourcebuffer will cause multiple unnecessary NotifyDataArrived to the MediaFormatReader when it could only be done once. Additionally, it ensures that the media duration is updated prior to the reader actioning on the notification.
Extra: mEnded is only ever accessed on the main thread, there's no need to make it atomic.
MozReview-Commit-ID: IKq7IRBbWic
--HG--
extra : rebase_source : 6cf18b1f71f5ee6c8e82c73bdd2857e783f343b8
The duration in the MediaDecoder is the canonical. It has as such a more up to date value than the mirror.
Under some circumstances, the MDSM may have reached the end of media playback before the duration mirror had time to update. So perform the currentTime adjustment in the MediaDecoder instead.
MozReview-Commit-ID: 1RFr4mT5LpA
--HG--
extra : rebase_source : 3151d86561b53d5d1922c7c16f042792bfd47283
With MediaSource, the duration is always known and exact. It is entirely possible that we have played data at some point, then removed that data and adjusted the duration.
MozReview-Commit-ID: HZe2yXtQfIL
--HG--
extra : rebase_source : be1b57575c28142d6b3091b23894a7e4e1c9b405
See w3c/MSE Issue 19, 20 & 26.
Changing the duration now can never call the range removal algorithm. An explicit call to remove must be used for range removal.
This spec change performed the following:
- Require remove() for all Range Removals
MozReview-Commit-ID: 860PnQ9yrbc
--HG--
extra : rebase_source : 31591e537706979cccedfedb2f2320b0c9681d22
It is incorrect to assume that the seeking attribute will still be true once the seeking event handler gets to run. Seeking may have completed between the time the seeking event was queued and the time the seeking env is fired.
MozReview-Commit-ID: CZFFotMyaIu
--HG--
extra : rebase_source : 32f9b56520020aaad26cc4564cf9f15ddad8d055
Back when it was added, it was used, but it is not anymore, outside
test_base.py.
--HG--
extra : rebase_source : f0b9a4dab2985e89e9950eda774ae853c7de764c
We've been reading the mozconfig in MozbuildObject.from_environment to
check whether the mozconfig topobjdir matches the detected topobjdir.
Since bug 1278415, everything using the buildconfig python module now
calls MozbuildObject.from_environment, which reads the mozconfig. A lot
of things to that during the build. But none of them actually need the
data from the mozconfig, and the topobjdir match test has been breaking
things randomly on multiple occasions.
The topobjdir match test, however, really only needs to happen once:
when a mach command starts. So we can move the test to MachCommandBase,
where it belongs, and anything actively using MozbuildObject.mozconfig
will have the mozconfig read, but everything else won't.
On a Linux64 opt build, this brings down the number of times the
mozconfig is read during `mach build` from 979 to 9.
--HG--
extra : rebase_source : 6b340f1fcf73a3c3987033c37f8f14ef06a44f04
Now that we compile with cargo, we don't have fine-grained control over
the build flags used via environment variables detected in configure or
set in config.mk. We should just remove that dead code so nobody trips
over it.
We want to ensure that our automation builds don't pull in libraries
from crates.io, and we need --frozen support in cargo to do that. If we
don't have that support, we shouldn't build.
Prior to this change, SpecialPowers used the extension id to identiy
extension instances in inter-process messaging. This required that
an id be allocated from the content process side when loadExtension()
was called, but that made it impossible to test code that exercises the
code path in the AddonManager that allocates ids for extensions that do
not include an id in the manifest (it also made the loadExtension() api
clunky).
With this change, SpecialPowers allocates an internal identifier for
messaging, but this identifier is separate from extension ids.
Confusingly, we still store the actual extension id in an id property
on the object returned by loadExtension(), but there are enough tests
that reference this that it would be unnecessarily disruptive to get
rid of it so it stays for now...
MozReview-Commit-ID: G6xk1mBJJL8
--HG--
extra : rebase_source : a0891e5ba308972c35813f55274badf9edde62f7
extra : source : e8818ef3c28489e196d1db92cabf224861b693c9
Matt Woodrow
Randell Jesup
Jeff Walden
Yura Zenevich
Kris Maglione
Wes Kocher
Carsten "Tomcat" Book
Jean-Yves Avenard
Phil Ringnalda
Seth Fowler
Luke Wagner
Kyle Machulis
Olli Pettay
Alexandre Lissy
Hiroyuki Ikezoe
Mike Hommey
Dan Minor
Rail Aliiev
Sebastian Hengst
Nathan Froyd
Samael Wang
JW Wang
cku
Andrew Swan