Gecko no longer emits this notification, so there's no point handling it in
GMPProvider.
MozReview-Commit-ID: BIvQCXN7LhF
--HG--
extra : rebase_source : b8340f4d411fa527f4c7af820d1bd4c657621a04
Gecko no longer emits these notifications, so there's no point handling them in
the front end code.
MozReview-Commit-ID: KGysG56m3QO
--HG--
extra : rebase_source : 0a08c058de25b41daceb409fc9da66d157489d18
This WebIDL enum/dict is used to pass messages from Gecko to the front-end
chrome JS code to notify it of problems starting up EME CDMs. This patch
removes some statuses from the enum that are no longer dispatched as of an
earlier patch in this series.
MozReview-Commit-ID: KjbUTvLBhjw
--HG--
extra : rebase_source : 9c9ddf6b2b9df845a2807186e8649684e9227ee3
We don't need this, and we don't seem to be using this anyway.
MozReview-Commit-ID: 7NCRO94PN3m
--HG--
extra : rebase_source : de91b099e5e536eb321584990f18025e08c7cc78
This ensures that when requests for keysystem access in the content process
retry, they do so on an up-to-date set of capabilities.
MozReview-Commit-ID: JxmlZnFhKYs
--HG--
extra : rebase_source : 6e02777be6a0692c7e157d3ab0a1952c3017c208
Currently the fxaccounts content server passes this through directly from its
configuration files, and accepts this as either containing the trailing /v1 or
not. On stage, it contains it, but on dev it does not.
In the near future, it should be possible to append the trailing /v1
unconditionally, as the FxA content server is being changed to never send it
down (which will be consistent with the other prefs), however it's done
conditionally as to not break autoconfig against stage in the mean time.
MozReview-Commit-ID: AStTm2hHVHQ
--HG--
extra : rebase_source : bf98cef357d5834e08a01b3c233a8ccb37243e64
The android 5.1.1 OMX decoder claims to support audio/opus
but crashes on the output of our mp4 demuxer. Work around
this by rejecting the mime type, allowing fallback to the
libopus-based AgnosticDecoderModule.
In any case, since we're shipping the libopus-based decoder
we're prefer to use it for consistency.
MozReview-Commit-ID: GQaTMALajnZ
--HG--
extra : rebase_source : fb43ddc6bd7b5ed92308124045ad2330a8043f46
Enable the rust mp4 parser code like we do on desktop.
MozReview-Commit-ID: 92XLeY2VdIM
--HG--
extra : rebase_source : 755b4b4619ff33f061695df023dd9968cabbac07
We actually target armv7, so we need this distinct triple
with the rust toolchain, while it's implicit with the
android ndk.
MozReview-Commit-ID: LUwdpOaWB6M
--HG--
extra : rebase_source : 820de90d0844e1519f9e02a583c8cc3abf1dfdc0
When dumping buffered messages in mochitest, this adds a new log line for every second's
worth of messages. Alternatively we could print the timestamp in brackets at the end of
each buffered message, but I found that in practice there tends to be many log messages
generated each second. This looks better for that case, but will look much worse if logs
are generated more than a second apart. I would be ok with either method.
MozReview-Commit-ID: Jkd9hOlmiGZ
--HG--
extra : rebase_source : 6c7a10235c2c7ca4a483ea7f1f37e18690974ce0
I believe the current behaviour of buffering messages outside of a test is wrong. For example:
1. INFO logged -> gets buffered
2. TEST-START logged -> doesn't get buffered
3. Test fails and buffer dumped -> INFO looks like it happened after the TEST-START
I think this is very confusing as developers trying to debug a test will think that INFO message
is happening somewhere inside their test when in reality it isn't.
MozReview-Commit-ID: Jkd9hOlmiGZ
--HG--
extra : rebase_source : f016cb069abcb71587a1d9df143e4796ffa69b3b
For some reason we have a 'buffering' parameter in the MessageLogger constructor, but
then rather than using this, the mochitest harness modifies state after instantiation.
Using the constructor is easier to understand, and simplifies some of the logic in the
next couple of patches.
MozReview-Commit-ID: Jkd9hOlmiGZ
--HG--
extra : rebase_source : eb2b5b7d647d69229cca5495f6f950c5fcf80809
See inline documentation for why I'm using the frameLoader instead
of just directly comparing the selectedBrowser to the browser
requesting the prompt.
MozReview-Commit-ID: D9ahuth6eLC
--HG--
extra : rebase_source : 6fe207cf23d71fa6702ea55e3096920761e2f83a
