1922798 - OpenH264/Widevine installation stuck at "will be installed shortly" when Temp folder inaccessible by permissions

Status: REOPENED

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

Description

[u759320]

Attachment: error.png

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

Steps to reproduce:

Go to about:addons.

Actual results:

The OpenH264 and Widevine plugins are never installed, even after turning a VPN service on and off and toggling DRM in the Firefox settings.

Expected results:

Firefox should show a clear error message when it isn't possible to install these plugins.

Comment 1

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

Could you provide your about:support? The media.gmp-gmpopenh264.* prefs are the most interesting to me. Thanks!

Comment 2

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

Also, if you are willing, could you please:

1. Create/set the pref media.gmp.log.level as an integer, and set it to 5.
2. Restart Firefox.
3. Go to the menu drop down, More Tools, and select Browser Console.
4. With that open, go to about:addons, press the gear icon in the upper right hand corner of the page, and select Check For Updates.
5. Wait a few seconds, copy the output in the Browser Console, and attach it to this bug.

Thanks!

Comment 3

[u759320]

I had created this issue for a Reddit user expecting him to open the link, but he didn't and then managed to figure out how to solve this:

I was finally able to solve it, the problem that all permissions were removed in the "temp" folder so really thank you very much for the help!

Comment 4

[Marco Bonardo [:mak]]

Reopening for another "user report" in https://bugzilla.mozilla.org/show_bug.cgi?id=1900521#c10, it looks like if the temp folder permissions are messed up, the download gets stuck in "will be installed shortly" instead of showing a clear error.

Comment 5

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

We store the addon while downloading in the temporary folder:
https://searchfox.org/mozilla-central/rev/b784b4ed27d0fc41a9bbce7d666e1cfcac4778be/toolkit/mozapps/extensions/internal/ProductAddonChecker.sys.mjs#437

This maps to NS_OS_TEMP_DIR:
https://searchfox.org/mozilla-central/rev/b784b4ed27d0fc41a9bbce7d666e1cfcac4778be/dom/system/PathUtils.h#253

Which in turn maps to DirectoryService_OS_TemporaryDirectory:
https://searchfox.org/mozilla-central/rev/b784b4ed27d0fc41a9bbce7d666e1cfcac4778be/xpcom/io/nsDirectoryService.cpp#348

Which finally results in an actual path:
https://searchfox.org/mozilla-central/rev/b784b4ed27d0fc41a9bbce7d666e1cfcac4778be/xpcom/io/SpecialSystemDirectory.cpp#475-507

We never check the path for appropriate permissions. We just assume everywhere in the code that we have write permissions to the temporary folder. This isn't a unique problem to GMP, but it is probably the most user visible feature that gets stuck by this.

Comment 6

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

There are multiple directory providers, one of which is able to provide the profile directory which we definitely have write access to. We could consider falling back to a different provider for an alternative temporary directory, that is <PROFILE_DIR>/tmp or something, as we know we have write access to the profile. We would have to add logic to clear this folder on startup and/or shutdown though.

Comment 7

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

There are a few open questions:

1. Should we just move the temp folder to be always in the profile? We know that is writable and generally anything that wants a temp folder wants to write to it.
2. How many users are impacted? We should create a telemetry probe for this perhaps.

I imagine we are the only component getting an understandable bug report here, because the other use cases are deeper in the stack and hard to make a connection.