As per Bug 1355252, the EME spec requires our
navigator.requestMediaKeySystemAccess() function to reject request for
configurations which don't contain at least one MediaKeySystemCapabilities
(audioCapabilities or videoCapabilities).
That's step 15 of this algorithm:
https://w3c.github.io/encrypted-media/#get-supported-configuration-and-consent
We also shouldn't be assuming that WebM and MP4 normatively imply a specific
set of codecs and codec constraints, as that violates step 10 of the "Get
Supported Capabilities for Audio/Video Type" algorithm.
https://w3c.github.io/encrypted-media/#get-supported-capabilities-for-audio-video-type
Making this change has the effect of causing us to reject configurations with
MediaKeySystemCapabilities where those capabilities don't specify a codec
string.
This patch adds a deprecation warning to encourage authors to make their sites
spec compliant.
MozReview-Commit-ID: 6kM9LATDfy6
--HG--
extra : rebase_source : 96763bd49cbebb81ac565a8862cb0ad97838181f
extra : source : 9df49a410082d68041377dabbbebfb458a580041
This makes it easier to tell what's going on; whether we've created a
MediaKeySystemConfiguration which can persist state.
MozReview-Commit-ID: L4dbmMVYhsM
--HG--
extra : rebase_source : e47e60f5091b6b5477b2c8bd63ba408922706082
This will enable us to re-use the logging code in MediaKeySystemAccess to log
the configuration we end up instantiating the MediaKeySystemAccess with.
MozReview-Commit-ID: AMnauhMLJ1R
--HG--
extra : rebase_source : a2dfeb7b263108ac1c60bfe2f47755e0a73d6324
We want requests for MediaKeySystemAccess with persistentState to be rejected
if the window is in Private Browsing mode. This is primarily so that users in
Private Browsing mode don't unknowningly use up their "device limits"; some DRM
streamers have limits on the numbers of unique devices that can be
provisioned/used in a given time period, and the device ID is persisted in the
persistent state. So if we're flushing that state, the user will use up one of
their device quota on every new session, and quickly hit their limit, and be
unable to continue watching DRM video.
MozReview-Commit-ID: JWNO1kcU2ST
--HG--
extra : rebase_source : ad4e22629acfdd82aff8ead764949939726adbf4
Step 10 of EME's "Get Supported Capabilities for Audio/Video Type" algorithm
says we can assume default codecs only if a container normatively implies a
specific set of codec and codec constraints. Our code assumes that WebM implies
Vorbis/VP8 and MP4 implies AAC/H.264, but those aren't actually normatively
required by either of these containers' specifications. So we shouldn't assume
these containers imply those codecs.
MozReview-Commit-ID: G9TDOmrjhpp
--HG--
extra : rebase_source : 2f040d76c8cb240359401fe1dc1e3eefa029d77b
Turns out that Chrome treats the robustness values as SW_SECURE_DECODE to mean
that SW_SECURE_CRYPTO is also supported. So we'd better follow suit...
MozReview-Commit-ID: 6J68IsSQhyL
--HG--
extra : rebase_source : 08baf83f0812f52670f1643e7e86ced0a0972f64
X11.h #defines 'Status' and 'Failed' and 'Succeeded' which conflicts with
the enum in DetailedPromise. So rename the 'Status' enum in DetailedPromise
so that the build works on Linux.
Some of my changes here caused DetailedPromise to be included in more
places that it was before, which caused build failures on Linux.
MozReview-Commit-ID: KV5xKixXR3J
--HG--
extra : rebase_source : ef6cab901d74b78f613660f263f5e453d6044536
This is required for the browser clearing persistence tests to pass.
MozReview-Commit-ID: Ai9qc6Ds1IG
--HG--
extra : rebase_source : 80c2133e26742410fda983e3c18c35736fc013d0
This means the EME PDM implementation can safely tell when a CDMProxy is a
ChromiumCDMProxy, so we can create an appropriate MediaDataDecoder for it (in
the next patch).
MozReview-Commit-ID: CpL6QRa7SwJ
--HG--
extra : rebase_source : 3821c378c73067066f3cc67499680bdf546fb4f0
Otherwise navigator.requestMediaKeySystemAccess() doesn't know whether we have
a CDM or not.
MozReview-Commit-ID: Hic6UneGA4u
--HG--
extra : rebase_source : 68ce766bede0f5c8e41de3a3f9e46b6ef88cab96
Changed |print("enum ID : uint32_t {", file=output)| to |print("enum HistogramID : uint32_t {", file=output)| at line 53 of the file |toolkit/components/telemetry/gen-histogram-enum.py|, and then replaced all the textual occurrences of |Telemetry::ID| to |Telemetry::HistogramID| and |ID| to |HistogramID| in 43 other files.
This means it can be used in other CDMProxies, specifically the
upcoming Chromium CDM code in bug 1315850.
MozReview-Commit-ID: G26xclqhtSw
--HG--
extra : rebase_source : 041c2cb41ba444e0dea8de3ddcc6a119d480f4f7
extra : source : c7f66edac83a6662d99f59a48f70c539f8ccecc8
This means it can be used in other CDMProxies, specifically the
upcoming Chromium CDM code in bug 1315850.
MozReview-Commit-ID: G26xclqhtSw
--HG--
extra : rebase_source : c4c99063f7423b8cbbd49865d2d45eca32c254ce
extra : source : c7f66edac83a6662d99f59a48f70c539f8ccecc8
