This is the easy stuff -- everything but mobile/android/base/Makefile.in.
MozReview-Commit-ID: 5x2z97AHUrR
--HG--
extra : rebase_source : 531fd41d367cad071b209b85ca5b5602fd7cbf7b
This is already true for the audio sources. It should be for all.
Crashtests showed that shutting down amidst the async init can lead to
double-stops. It is impossible to completely protect yourself from them without
waiting for all queued operations to resolve (results to become known) before
taking action. Doing that would require a refactor in MediaManager and cause
higher latency for device operations so it seems like the wrong way to go.
MozReview-Commit-ID: 5Cci6whzTL7
--HG--
extra : rebase_source : 18efef4e294ac2b02753721ca5813bcbf63e3111
This so that SourceListener can keep its internal state in sync with the result
of the start operation.
MozReview-Commit-ID: Cgl5TFnpCeW
--HG--
extra : rebase_source : 4a7e8c1217b0db3879312d4b33dc74227e969608
I can't for the life of me figure out how we get into the situation
where the block change list is empty here, or how we can get past some
of the existing null checks in the code, but we can at least add some
more checks to hopefully ensure we don't crash...
MozReview-Commit-ID: 168G94IyrWt
--HG--
extra : rebase_source : b6ada7bfb755ae285f0010bd6eff2e305fc5fbf0
I can't for the life of me figure out how we get into the situation
where the block change list is empty here, or how we can get past some
of the existing null checks in the code, but we can at least add some
more checks to hopefully ensure we don't crash...
MozReview-Commit-ID: 168G94IyrWt
--HG--
extra : rebase_source : 6918da94d4f42adad1978055ea49e7040e069368
Autoplay of audible media should be blocked in documents until they have a user
gesture in them, or in a same-origin parent document. This patch adds tests for
those cases.
MozReview-Commit-ID: B4FQhPOukId
--HG--
extra : rebase_source : 38d77ce42ec5f4edb0119ba2ccf03f53cd8cdb00
The logging added in this patch was landed to help debug very rare shutdown
failures on android, but the logging runs on other platforms and is annoying.
No one is looking at fixing the rare shutdown problem on Android. So remove the
logging until fixing the shutdown failure becomes a priority.
FFVPXRuntimeLinker could not handle file paths that contain characters outside the current system code page on Windows. This patch will fix it by using wide char APIs.
MozReview-Commit-ID: 9ES1xFELjDs
--HG--
extra : rebase_source : 4bdc082bd6db9263b41fe74d524e0a4d98802ea8
extra : intermediate-source : 8afa22df3893c678884e3a0811fb6c82790c1a3c
extra : source : c6f916a967a78e176bdb699a85e194bbdc372bce
If a camera returns no capabilities we interpret it as it being able to handle
any capability we throw at it. However, we also end up trying to start it with
the default capability of 0x0@0. This often works, but we can crash when
rescaling it to the chosen target capability 0x0@0.
With this patch we inject up to two default capabilities, one at 640x480@30 and
one at 1280x720@30. With constraints present we'll try to adjust these defaults
so they fit within the constraints while at the same time preserve the
aspect ratio given by prefs.
MozReview-Commit-ID: 3mr7Li5TTbV
--HG--
extra : rebase_source : c525c2fd8d60f5dece548216caefc4976e9afb0b
This will lead to less ipc calls, hopefully speeding up getUserMedia for many
devices.
This also lets us inject any hardcoded capabilities into the candidateSet in
the future (read: next patch).
MozReview-Commit-ID: HjIhRK1nVA1
--HG--
extra : rebase_source : f58e16c45f7bd6738ce0a0527dc86854f804bc7b
Remove references to the mp4parse_log() method which was
removed in this release. Instead we default to the logging
implementation provided by libgkrust.
MozReview-Commit-ID: KKzeEcB5UiP
--HG--
extra : rebase_source : 2777f13a006c09afb82772475d25245b2752524c
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b
