Name Description Size
CDMCaps.cpp 3666
CDMCaps.h 2631
CDMProxy.h IsExclusive = 9313
DecryptorProxyCallback.h 2062
DetailedPromise.cpp static 3681
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. 3938
EMEUtils.cpp 2217
EMEUtils.h 3113
MediaEncryptedEvent.cpp 3964
MediaEncryptedEvent.h 2005
MediaKeyError.cpp 1029
MediaKeyError.h 968
MediaKeyMessageEvent.cpp 3858
MediaKeyMessageEvent.h 2065
MediaKeySession.cpp 23150
MediaKeySession.h 4297
MediaKeyStatusMap.cpp 3241
MediaKeyStatusMap.h 2926
MediaKeySystemAccess.cpp static 48507
MediaKeySystemAccess.h 2857
MediaKeySystemAccessManager.cpp 27217
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 9789
MediaKeySystemAccessPermissionRequest.cpp static 3162
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. 3160
MediaKeys.cpp 22926
MediaKeys.h 6947
mediadrm 7 1289