Tests that a fragmented MP4 file without a PSSH, but with encrypted valid
tracks with valid TENC boxes, is able to load with EME. This is a test for
the code path added in bug 1300069.
We setup MSE before starting up EME, so that we exercise the "waiting for
cdm" step in the MediaDecoderStateMachine, which was regressed in bug 1300069.
MozReview-Commit-ID: BXgdzAikWoH
--HG--
extra : rebase_source : b03910c96c8f61622ce7bc9fb7b53adc209526a4
The patch in bug 1300069 introduced an inconsistency between what the
MediaDecoderStateMachine and the MediaFormatReader consider an encrypted
stream. The MDSM considered a stream encrypted if mInfo.IsEncrypted() is true,
and that only takes into account the PSSH. Whereas the MFR only considers the
presence of a TENC box to indicate encryptedness. This would cause the MDSM
to not wait for the CDM before trying to start decoding. So if you setup the
MediaSource before setting the MediaKeys on the MediaElement, you'll end up
trying to create an EME decoder without a CDMProxy, and that causes a null
pointer deref and crash.
This patch ensures that the MDSM and the MFR use the same logic to determine
whether a stream is encrypted.
MozReview-Commit-ID: KGuYTuP9XDL
--HG--
extra : rebase_source : 85b303597a401a69f7e4ac63a267d8c8eb52ffa5
If you want to run tests on Linux32 and Linux64, you use trychooser syntax like
"-u all[Ubuntu]" which taskcluster supports, but if you also built ASan, and
want tests on ASan, there's no supported documented way to get them. That sounds
like an edge-case, except that to get tests to run on WinXP or Win8 you have to
explicitly list them, so to get tests on every platform you build you have to
list all of them, and if ASan is one of them you have to somehow know to dig
around in the .yml and to know that linux64-asan is the thing to dig out.
MozReview-Commit-ID: 2REf0cUWmK8
--HG--
extra : rebase_source : cb77ff3e016939c94ac05964a6db809fe10aaa1a
The trychooser website advertises 'Android 4.3' as the alias to choose Android
tests in [] syntax, but without support for that in taskcluster, someone who
wants both opt and debug tests would need to guess, with no support or
documentation, that they should use [Android 4.3,android-4.3-arm7-api-15]
MozReview-Commit-ID: 4rEKcvqAfDH
--HG--
extra : rebase_source : 336d3a787569e14e5ae8608902e6e557ef2ce6c3
Currently make check loops over all directories and runs each test file in PYTHON_UNIT_TESTS
individually. This patch instead creates a single top-level check target that runs
|mach python-tests|. This should make automation more similar to running locally, be a bit
quicker and make it easier to pull python tests out of make check completely at a future date.
MozReview-Commit-ID: 4Hg4zdFyc61
--HG--
extra : rebase_source : 31d0c38a76c11b75d3bf569f2bf22a0666161726
When attempting to run mach from a make target, there were failures on OSX due to an objdir
mismatch:
https://dxr.mozilla.org/mozilla-central/rev/7c576fe3279d87543f0a03b844eba7bc215e17f1/python/mozbuild/mozbuild/base.py#656
The two detected objdirs were "<objdir>" and "<objdir>/x86_64". I believe this should not
count as a mismatch, otherwise it would not be possible to run a mach command from the
x86_64 directory.
MozReview-Commit-ID: CXDEABNWX8L
--HG--
extra : rebase_source : 9daeaf372d872921e7b2854eee0313b5adc0e707
As it turns out, the workaround used to detect "not activated" service worker registrations works only
in e10s pages. In non e10s, service worker registrations are returned even if they are not in activated
state. Here we add the currently associated worker to the registration info, which will be used
to determine if the service worker is activated by about debugging.
MozReview-Commit-ID: ImeZcXQdBtO
--HG--
extra : rebase_source : f7e023708f8954b978b189025fd0b06c587d6a8e
Make contentDocumentChanged and isContentDocumentDisplayed calls require
the caller to pass in a window object, so that we can get the widget and
GeckoLayerClient from the window object. This way these calls no longer
depend on having a global layer client in AndroidBridge.
Add AndroidCompositorWidget to act as the intermediary between gfx code
and GeckoLayerClient, in place of AndroidBridge. AndroidCompositorWidget
currently inherits from InProcessCompositorWidget, but when Android
eventually supports OOP compositing, it will be made to inherit from
CompositorWidget directly.