| CDMCaps.cpp |
|
3666 |
| CDMCaps.h |
|
2631 |
| CDMProxy.h |
IsExclusive = |
11161 |
| clearkey |
|
|
| DecryptorProxyCallback.h |
|
2021 |
| DetailedPromise.cpp |
static |
3225 |
| DetailedPromise.h |
This is pretty horrible; bug 1160445.
Extend Promise to add custom DOMException messages on rejection.
Get rid of this once we've ironed out EME errors in the wild.
|
3682 |
| EMEUtils.cpp |
|
9134 |
| EMEUtils.h |
|
3478 |
| KeySystemConfig.cpp |
static |
15630 |
| KeySystemConfig.h |
aIgnored |
7760 |
| KeySystemNames.h |
|
2345 |
| mediadrm |
|
|
| MediaEncryptedEvent.cpp |
|
3822 |
| MediaEncryptedEvent.h |
|
1979 |
| mediafoundation |
|
|
| MediaKeyError.cpp |
|
1003 |
| MediaKeyError.h |
|
909 |
| MediaKeyMessageEvent.cpp |
|
3682 |
| MediaKeyMessageEvent.h |
|
2052 |
| MediaKeys.cpp |
|
30407 |
| MediaKeys.h |
|
9196 |
| MediaKeySession.cpp |
|
23900 |
| MediaKeySession.h |
|
4616 |
| MediaKeyStatusMap.cpp |
|
3427 |
| MediaKeyStatusMap.h |
|
2988 |
| MediaKeySystemAccess.cpp |
static |
47684 |
| MediaKeySystemAccess.h |
|
2616 |
| MediaKeySystemAccessManager.cpp |
|
28119 |
| MediaKeySystemAccessManager.h |
MediaKeySystemAccessManager implements the functionality for
Navigator.requestMediaKeySystemAccess(). The navigator may perform its own
logic before passing the request to this class, but the majority of
processing happens the MediaKeySystemAccessManager. The manager is expected
to be run entirely on the main thread of the content process for whichever
window it is associated with.
As well as implementing the Navigator.requestMediaKeySystemAccess()
algorithm, the manager performs Gecko specific logic. For example, the EME
specification does not specify a process to check if a CDM is installed as
part of requesting access, but that is an important part of obtaining access
for Gecko, and is handled by the manager.
A request made to the manager can be thought of as entering a pipeline.
In this pipeline the request must pass through various stages that can
reject the request and remove it from the pipeline. If a request is not
rejected by the end of the pipeline it is approved/resolved.
The pipeline is structured in such a way that each step should be executed
even if it will quickly be exited. For example, the step that checks if a
window supports protected media is an instant approve on non-Windows OSes,
but we want to execute the function representing that step to ensure a
deterministic execution and logging path. The hope is this reduces
complexity for when we need to debug or change the code.
While the pipeline metaphor generally holds, the implementation details of
the manager mean that processing is not always linear: a request may be
re-injected earlier into the pipeline for reprocessing. This can happen
if the request was pending some other operation, e.g. CDM install, after
which we wish to reprocess that request. However, we strive to keep it
as linear as possible.
A high level version of the happy path pipeline is depicted below. If a
request were to fail any of the steps below it would be rejected and ejected
from the pipeline.
Request arrives from navigator
+
|
v
Check if window supports protected media
+
+<-------------------+
v |
Check request args are sane |
+ |
| Wait for CDM and retry
v |
Check if CDM is installed |
+ |
| |
+--------------------+
|
v
Check if CDM supports args
+
|
v
Check if app allows protected media
(used by GeckoView)
+
|
v
Provide access
|
10181 |
| MediaKeySystemAccessPermissionRequest.cpp |
static |
3142 |
| MediaKeySystemAccessPermissionRequest.h |
This class encapsulates a permission request to allow media key system
access. The intention is not for this class to be used in all cases of EME,
but only when we need to seek explicit approval from an application using
Gecko, such as an application embedding via GeckoView.
media.eme.require-app-approval should be used to gate this functionality in
gecko code, and is also used as the testing pref for
ContentPermissionRequestBase. I.e. CheckPromptPrefs() will respond to having
`media.eme.require-app-approval.prompt.testing` and
`media.eme.require-app-approval.prompt.testing.allow` being set to true or
false and will return an appropriate value to allow for test code to short
circuit showing a prompt. Note that the code using this class needs to call
CheckPromptPrefs and implement test specific logic, it is *not* handled by
this class or ContentPermissionRequestBase.
Expects to be used on main thread as ContentPermissionRequestBase uses
PContentPermissionRequest which is managed by PContent which is main thread
to main thread communication.
|
3168 |
| metrics.yaml |
|
1353 |
| moz.build |
|
1450 |