1587543 - Bump openh264 fallback downloader to version 1.8.1.1

Status: VERIFIED FIXED

(Core :: WebRTC: Audio/Video, task, P1)

Description

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

If we choose to mitigate bug 1587421 via my proposed solution in bug 1587533 we should update the fallback downloader to reflect the new dummy version. This should be done once we've tested and are rolling on the fix in bug 1587537.

Comment 1

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Attachment: Bug 1587543 - Bump OpenH264 fallback downloader to 1.8.1.1. r?callek

This change will cause Firefox to re-download the OpenH264 GMP if it already has
the 1.8.1 version. This is being done to mitigate and issue where clients that
already downloaded that version on previous versions of Firefox did not clear
the mac quarantine attribute that prevents the lib being loaded in MacOS
Catalina.

Newer versions of Firefox will clear the attribute on download, so we want to
trigger a re-download by those clients. We would typically expect this to be
done by balrog, but we update these fallback rules to cover the edge case where
balrog is not available and in order to keep these rules in step with those on
balrog.

The binaries pointed to by this 1.8.1.1 version are the same as the 1.8.1
version. This change is solely to trigger a re-download.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/18add174861c
Bump OpenH264 fallback downloader to 1.8.1.1. r=Callek

Comment 3

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/18add174861c

Comment 4

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Comment on attachment 9100968 [details]
Bug 1587543 - Bump OpenH264 fallback downloader to 1.8.1.1. r?callek

Beta/Release Uplift Approval Request

• User impact if declined: The fallback downloader and the rules for balrog (changed in bug 1587537) will have different OpenH264 versions. The result of this would be that if Firefox is ever unable to reach balrog, it would download a different version of OpenH264 (per the fallback rules), after which it would re-download the version in the balrog rules once it was able to reconnect to balrog.

This also covers a case where a user that cannot reach balrog and has updated to Catalina will not have their OpenH264 plugin updated, resulted in the quarantine attribute not being cleared, and thus breaking h264 webrtc calling.

• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None.
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low risk as the change is small and straight forward.
• String changes made/needed: None.

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Simplifies developer workflow by ensuring that the balrog rules and fallback downloader are in sync.
• User impact if declined: The fallback downloader and the rules for balrog (changed in bug 1587537) will have different OpenH264 versions. The result of this would be that if Firefox is ever unable to reach balrog, it would download a different version of OpenH264 (per the fallback rules), after which it would re-download the version in the balrog rules once it was able to reconnect to balrog.

This also covers a case where a user that cannot reach balrog and has updated to Catalina will not have their OpenH264 plugin updated, resulted in the quarantine attribute not being cleared, and thus breaking h264 webrtc calling.

• Fix Landed on Version: 71.0a1
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low risk as the change is small and straight forward.
• String or UUID changes made by this patch: None.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9100968 [details]
Bug 1587543 - Bump OpenH264 fallback downloader to 1.8.1.1. r?callek

Fx71 is already on Beta, so I'm moving the Beta request over the Release under the assumption that the intent of the request was for Fx70.

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

Is there any testing or verification you can suggest, that might help with our confidence for this uplift to release?

Comment 7

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

(In reply to Liz Henry (:lizzard) from comment #6)

Is there any testing or verification you can suggest, that might help with our confidence for this uplift to release?

Sure. Steps to test:

• Start Firefox with a new profile for this test.
• Open about:config and create and set the media.gmp-manager.url.override pref to a non existent URL, for example https://www.im-a-bad-url-that-doesnt-exist.bad/foo/
• Open the profile dir and ensure that the gmp-gmpopenh264 does not already exist.
  • If the directory exists, delete it and restart Firefox before continuing.
• Navigate to about:addons -> plugins
  • The OpenH264 should indicate that install will take place shortly. Note there is a small chance that the plugin will be installed prior to navigating to this page.
• Click on the cog menu and select Check for Updates. This should install the plugin.
• Ensure that the gmp-gmpopenh264 directory now exists in the profile dir, and contains a sub-directory named 1.8.1.1

By setting media.gmp-manager.url.override to a bad location we ensure that Firefox is unable to find the expected update information, this forces us to use the fallback downloader. So if we see the correct download after doing the above we know the downloader fetched using a fallback URL.

Our logging around this isn't as nice as I'd expect -- I'd hoped for an easy to emit log that indicates the fallback was used, but I don't currently see one. I have verified that the above steps use the fallback on my local machine, by hacking the fallback so it creates a differently named dir when it's used instead of balrog. I'll look at creating a bug for better logging here.

Comment 8

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Bug 1591176 created to track adding a log as discussed at the end of my prior comment.

Comment 9

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello! While following the STR from comment 7 with Firefox 71.0b4 (20191024095932) the "OpenH264 Video Codec" is correctly updated to version 1.8.1.1 respecting the expected results from comment 7 and the version number in about:addons-> Plugins -> OpenH264 Video Codec tab. The testing was performed on Windows 10x64, macOS 10.14 and Ubuntu 18.04.

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9100968 [details]
Bug 1587543 - Bump OpenH264 fallback downloader to 1.8.1.1. r?callek

Fix for video issue, verified in nightly, OK for uplift to m-r for 70.1

Comment 11

[Ryan VanderMeulen [:RyanVM]]

I could see taking this as a ride-along if we ship a 68.2.1esr release anyway, but I wouldn't spin a release just for it either.

Comment 12

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/releases/mozilla-release/rev/fb229825695e

Comment 13

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello!
Verified the issues using Firefox 70.0.1 (20191029231030) from comment 12 on Windows 10x64, Ubuntu 18.04 and macOS 10.14. The expected results are met as in comment 7.
Leaving ni? on myself to verify it when it lands on esr. Thank you!

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

Adding to 70.0.1 release notes as "Update OpenH264 video plugin for macOS 10.15 users"

Comment 15

[Pascal Chevrel:pascalc]

Comment on attachment 9100968 [details]
Bug 1587543 - Bump OpenH264 fallback downloader to 1.8.1.1. r?callek

Fix for video issue, low risk patch now on all our branches except ESR, uplift approved for ESR 68.3

Comment 16

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-esr68/rev/cf06c61df5b3

Comment 17

[Alexandru Trif, Desktop Test Engineering [:atrif]]

The issue is verified using Firefox 68.3.0esr (20191104104514) from comment 16 and STR from comment 7 on Windows 10x64, macOS 10.14 and Ubuntu 18.04.