1763978 - Widevine DRM breaks when using a non-default profile folder in 99.0 Windows-x64

Status: REOPENED

(Core :: Audio/Video: GMP, defect, P3)

Description

[anzz1]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0

Steps to reproduce:

Go to about:support -> Create New Profile. In the profile wizard choose a custom (empty) folder for the configuration (i.e. do not use the default folder). In my test example firefox.exe is in "C:\Program Files\Mozilla Firefox\firefox.exe" and the custom profile folder is "Z:\Firefox\Profiles\test".

Actual results:

Widevine breaks on latest FF 99.0 (build id 20220330194208, win-x64) when using a non-default profile folder.

Netflix fails with error code F7702-1103 and in console Uncaught Promise is shown with these details:

data: Exception { name: "NS_ERROR_FAILURE", result: 2147500037, lineNumber: 0, … }
details: "[Exception... "Failure" nsresult: "0x80004005 (NS_ERROR_FAILURE)"
location: "<unknown>" data: no]"
message: "Unable to create MediaKeys. "

Widevine test page at https://bitmovin.com/demos/drm fails with

The MediaKey object could not be created/initialized
(DRM_MEDIA_KEY_INITIALIZATION_FAILED)

Expected results:

Widevine should work when the profile is in different path than the default. The addon does get downloaded in the "gmp-widevinecdm" folder just fine and by diffing the profile folders it seems superficially that there is nothing wrong. It just does not work. I'm suspecting it is a sandbox issue.

Comment 1

[anzz1]

media.gmp-widevinecdm.abi = x86_64-msvc-x64
media.gmp-widevinecdm.version = 4.10.2391.0

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Toolkit::Startup and Profile System' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[anzz1]

<rant>
Also I would like to state that I hate DRM, this is just one example of how they cause extra work and headache while achieving absolutely nothing. Unfortunately the current situation is that many of the largest streaming services which are expected to work use Widevine and there is nothing that can be done about it, so this issue is something that requires attention.
</rant>

Comment 4

[anzz1]

Attachment: testEME.html

Comment 5

[anzz1]

Attachment: testEME.html

Comment 6

[anzz1]

Using this test page: https://gistcdn.githack.com/anzz1/85290d217833b3cd7d48147f52c22817/raw/testEME.html
this will be printed to console:

org.w3.clearkey supported
com.widevine.alpha supported

so the addon seems to be loaded, but the key initialization/exchange part is what fails I suppose. Some files are created in the profile\gmp\WINNT_x86_64-msvc\gmp-widevinecdm folder when running the bitmovin test/shaka player demo/netflix but maybe the sandbox does not let the widevine cdm addon to access/read those files?

I also found that while that JS test I pasted in gist returns that widevine is supported, this one https://shaka-player-demo.appspot.com/support.html says that "com.widevine.alpha": null

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mossop, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Jim Mathies [:jimm]]

I was not able to reproduce using a path that points to a second solid state drive on my system. The widevine plugin was installed in the profile folder I created for the custom profile and netflix worked as expected. What type of storage are you using for Z:?

Comment 9

[anzz1]

(In reply to Jim Mathies [:jimm] from comment #8)

I was not able to reproduce using a path that points to a second solid state drive on my system. The widevine plugin was installed in the profile folder I created for the custom profile and netflix worked as expected. What type of storage are you using for Z:?

I was using a RAMDisk created with ImDisk with a FAT32 filesystem, while Firefox itself is installed on a SSD with NTFS filesystem. So the reason could be differing filesystems between the FF install and profile folder?

Comment 10

[anzz1]

Update on this, still broken in latest FF 105.0.2 Win-x64. Filesystem doesn't matter, when system drive is NTFS and ramdisk is NTFS or FAT32, same result.

Steps to reproduce:

1. Close Firefox on your default profile.
2. Open "RAMDisk configuration" in ImDisk.
   Configuration options:
   -> Size: 2 GB
   -> Drive letter: Z:
   -> File System: NTFS
   -> Allocate Memory Dynamically: Disabled
   -> Press OK
3. Start Firefox Profile Manager with "firefox.exe -P"
4. Create New Profile:
   Name: "ramdisk"
   Folder: "Z:\Firefox\Profiles\ramdisk_profile"
5. Try the DRM test page mentioned earlier or any DRM-"protected" service like Netflix or Prime Video.
   Message will be shown "Firefox is installing components needed to play the audio or video on this page. Please try again later."
6. Restart Firefox, choose to use to "ramdisk" profile. Widevine and H264 plugins are now installed and can be found in about:addons -> Plugins.
7. Try a DRM page again, receive error.

Comment 11

[anzz1]

As for the reason why this even matters, I made a post about it on the community forum, if interested :
https://discourse.mozilla.org/t/regarding-firefox-and-heavy-disk-usage/106293 (warning; lengthy)

Comment 12

[Andrew Osmond [:aosmond] (he/him)]

I reproduced this locally, and fixed it. I was hoping it was the same issue that I've been tracking down causing crashes in the Widevine plugin process, but it doesn't seem so.

Comment 13

[Andrew Osmond [:aosmond] (he/him)]

Attachment: Bug 1763978 - Fix resolving final paths on Windows with third party driver mount points.

Some third party driver can create mount points without using the
Mount Manager. Without that, GetFinalPathNameByHandleW calls with
VOLUME_NAME_DOS cannot succeed. Instead we need to call it with
VOLUME_NAME_NT and convert the NT path to a DOS path using
QueryDosDevice to perform the mapping.

Prior to this patch, we would fail to load GMP plugins from
profiles mounted in a ramdisk, and potentially other situations.

See documentation for GetFinalPathNameByHandleW for more details:
https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlew

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/af9a460390e9
Fix resolving final paths on Windows with third party driver mount points. r=cmartin,mhowell

Comment 15

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/af9a460390e9

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:aosmond, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox113 to wontfix.

For more information, please visit BugBot documentation.

Comment 17

[Andrew Osmond [:aosmond] (he/him)]

I don't think we need to uplift.

Comment 18

[Kagami Rosylight [:saschanaz] (they/them)]

Backout happened in bug 1832469.