Name Description Size
CDMCaps.cpp 3666
CDMCaps.h 2631
CDMProxy.h IsExclusive = 11161
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 8929
EMEUtils.h 3415
KeySystemConfig.cpp static 15155
KeySystemConfig.h aIgnored 10084
KeySystemNames.h 2345
MediaEncryptedEvent.cpp 3822
MediaEncryptedEvent.h 1979
MediaKeyError.cpp 1003
MediaKeyError.h 909
MediaKeyMessageEvent.cpp 3682
MediaKeyMessageEvent.h 2052
MediaKeys.cpp 30407
MediaKeys.h 9196
MediaKeySession.cpp 24327
MediaKeySession.h 4728
MediaKeyStatusMap.cpp 3427
MediaKeyStatusMap.h 2988
MediaKeySystemAccess.cpp static 50682
MediaKeySystemAccess.h 3316
MediaKeySystemAccessManager.cpp 29506
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 11304
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 1450