The next version of the Widevine CDM 1.4.8.984 cannot load on Windows 10 as it appears to be blocked by the sandbox; running with MOZ_DISABLE_GMP_SANDBOX=1 and the 984 CDM works, but without that it fails to load on shaka player. STR: 1. Ensure your Google Chrome x64 Release is up to date, and open chrome://components and ensure the Widevine CDM is to date and version 1.4.8.984. 2. Copy the 984 widevinecdm.dll out of Chrome's install to overwrite the 970 CDM DLL in your Firefox at $Profile/gmp-widevinecdm/1.4.8.970/widevinecdm.dll. The Chrome CDM is located (on my machine) at: C:\Program Files (x86)\Google\Chrome\Application\59.0.3071.115\WidevineCdm\_platform_specific\win_x64 3. Startup Firefox Nightly x64 with the profile containing the new Widevine CDM. 4. Load shaka player, observe CDM fail to load: https://shaka-player-demo.appspot.com/demo/#asset=//storage.googleapis.com/shaka-demo-assets/angel-one-widevine/dash.mpd;lang=en-US

The 32bit CDM also fails to load as well.

This fails on Windows 7 as well, but isn't this expected behaviour at the moment? I don't see anything logged after permission is given to open the DLL.

OK, this is failing because it's now using psapi.dll. So to get it to work I had to pre-load psapi.dll. However, psapi.dll is only included for GetMappedFileNameW, which is exported from psapi.dll because they must still be compiling for Windows XP and Vista compatibility. I would have thought that they could now switch to targeting Windows 7+, in which case GetMappedFileNameW gets defined as K32GetMappedFileNameW and is exported from kernel32.dll, which is of course already loaded. I'm guessing we'll have to pre-load for now, but might be worth mentioning this to them to see if they can change their target version. Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=43aa6530d670a8ff851992a08dc814f10a1eb4a1

Comment on attachment 8889497 [details] [diff] [review] Pre-load psapi.dll for widevine CDM as it needs it for GetMappedFileNameW Review of attachment 8889497 [details] [diff] [review]: ----------------------------------------------------------------- Great, thanks for your quick response!

Pushed by bobowencode@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/c2ebc796b97b Pre-load psapi.dll for widevine CDM as it needs it for GetMappedFileNameW. r=cpearce

Comment on attachment 8889497 [details] [diff] [review] Pre-load psapi.dll for widevine CDM as it needs it for GetMappedFileNameW Approval Request Comment [Feature/Bug causing the regression]: Latest widevine support. [User impact if declined]: We will not be able to roll out the next version of widevine on Windows if we want to do that for Fx55. [Is this code covered by automated tests?]: EME code has automated tests using clearkey, which uses the same mechanism for pre-loading DLLs. [Has the fix been verified in Nightly?]: Yes on Win10 and Win7 both 64-bit. [Needs manual test from QE? If yes, steps to reproduce]: STR are in the description. [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: No [Why is the change risky/not risky?]: Very simple addition of a new system DLL to pre-load. [String changes made/needed]: None

Hi Bob, the work for CDM 984 is planned for 56. Is this needed for 55 or 56? Please confirm.

(In reply to Ritu Kothari (:ritu) from comment #9) > Hi Bob, the work for CDM 984 is planned for 56. Is this needed for 55 or 56? > Please confirm. I thought Chris mentioned that they might want this in 55, so I'll let him confirm if we need this.

I think we should target CDM 984 at 56, and not bother trying to get 970 pushed out to 55, as it's a bit late in the 55 cycle. So I don't think we should bother uplifting this, and just let it ride the trains in 56.

Bob: Google claim that the Widevine 984 CDM doesn't call GetMappedFileNameW. Are you 100% sure they're calling GetMappedFileNameW()?

(In reply to Chris Pearce (:cpearce) from comment #12) > Bob: Google claim that the Widevine 984 CDM doesn't call GetMappedFileNameW. > Are you 100% sure they're calling GetMappedFileNameW()? The DLL is definitely importing it from psapi.dll (could be in their code as GetMappedFileName). Just checked the latest version (1.4.8.1000) and it's still there.