Closed Bug 1548679 Opened 5 years ago Closed 5 years ago

Stop downloading OpenH264 plugin on Android

Categories

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

Unspecified
Android
task

Tracking

()

RESOLVED FIXED
mozilla69
Tracking Status
firefox-esr60 --- disabled
firefox66 - wontfix
firefox67 + wontfix
firefox67.0.1 --- wontfix
firefox68 blocking verified
firefox69 --- fixed

People

(Reporter: cpeterson, Assigned: drno)

References

Details

(Whiteboard: [geckoview:fenix:m5][bcs:p1][no-nag])

Attachments

(1 file, 1 obsolete file)

We need to determine whether downloading the OpenH264 plugin violates Google's Play Store "malicious behavior" policy.

Can users who have already downloaded the OpenH264 plugin continue to use it without violating the Play Store policy? How would these users know whether their downloaded plugin has critical security bugs and should no longer be used?

IIUC, we use OpenH264's encoder but Android's system decoder for WebRTC. We can't use the system H.264 encoder because it has too much latency.

Can we stop supporting H.264 WebRTC on Android and always negotiate VP9 instead?

I'm curious what Nils and others think - it seems this would mainly have an impact on WebRTC services that still use H.264 video, but do we even support those on Android?

Flags: needinfo?(drno)
Flags: needinfo?(astevenson)

I can't find the bug report atm, but I believe h264 stopped working recently and users were complaining about dirtyroulette and chatroulette not working in Fennec. We were surprised by the relatively high amount of WebRTC usage on mobile.

Flags: needinfo?(astevenson)

(In reply to Chris Peterson [:cpeterson] from comment #0)

We need to determine whether downloading the OpenH264 plugin violates Google's Play Store "malicious behavior" policy.

Can users who have already downloaded the OpenH264 plugin continue to use it without violating the Play Store policy?

I'm not a lawyer, but my guess would be yes they should.

How would these users know whether their downloaded plugin has critical security bugs and should no longer be used?

Yeah they would be left with the old plugin then.

IIUC, we use OpenH264's encoder but Android's system decoder for WebRTC.

No we use the OpenH264 decoder and encoder for WebRTC calls.

Android system decoder is only used for playback.

We can't use the system H.264 encoder because it has too much latency.

We don't even have any code to start using it.

Can we stop supporting H.264 WebRTC on Android and always negotiate VP9 instead?

Technically it is possible to only offer VP8 and VP9. But there are services out there which only support H264. So Firefox would stop working with these services.
Not supporting H264 also violates the spec (which is probably not the biggest concern right now, but for full awareness).

Flags: needinfo?(drno)

Since this issue is specifically about Google's Play Store policies, GeckoView-powered apps that are distributed through other stores (such as Firefox Reality) might still be able to download OpenH264.

Is downloading the plugin a workaround for MPEG LA license issues? Or could we bundle the OpenH264 plugin in the Fennec or Fenix APKs?

Bundling it with the APKs is a non-starter because of licensing costs. (IMHO)

(In reply to Chris Peterson [:cpeterson] from comment #4)

Is downloading the plugin a workaround for MPEG LA license issues? Or could we bundle the OpenH264 plugin in the Fennec or Fenix APKs?

As soon as we bundle H264 code with Firefox Mozilla would have to start to pay royalties to MPEG LA. We are downloading the plugin from a Cisco server so that MPEG LA charges Cisco for the costs.
So bundling in any form is pretty much a non-starter for Mozilla.

(In reply to Adam Stevenson [:adamopenweb] from comment #2)

I can't find the bug report atm, but I believe h264 stopped working recently and users were complaining about dirtyroulette and chatroulette not working in Fennec. We were surprised by the relatively high amount of WebRTC usage on mobile.

Yes, that was Bug 1535766, which delayed the release of Fennec 66 by a week or so.

We need to determine whether downloading the OpenH264 plugin violates Google's Play Store "malicious behavior" policy.

What part of it is malicious? Would making it an optional but suggested download (requiring explicit user interaction before a download starts) be acceptable?

Don't panic, we're following up. :-)

(In reply to Andreas Bovens [:abovens] from comment #8)

We need to determine whether downloading the OpenH264 plugin violates Google's Play Store "malicious behavior" policy.

What part of it is malicious?

The Play Store's "malicious behavior" policy just means Play Store hosted apps are not supposed to download executable code from third-party servers. Google wants to be able to analyze all the code for apps hosted in the Play Store. (This policy obviously doesn't cover apps installed from third-party stores like F-Droid.)

Would making it an optional but suggested download (requiring explicit user interaction before a download starts) be acceptable?

I don't know. That's a good question.

(In reply to Peter Saint-Andre [:stpeter] from comment #9)

Don't panic, we're following up. :-)

Peter, do you have any updates from Google? Does "Don't panic" mean you think we might not have to rip out OpenH264?

Discussions are underway. Although we're waiting to hear back, I did request that we be granted an exception if those are available. At this point, it seems best to figure out what we'd need to change if we rip out OpenH264, but not actually do the work until we figure out if it's necessary.

(In reply to Peter Saint-Andre [:stpeter] from comment #11)

At this point, it seems best to figure out what we'd need to change if we rip out OpenH264, but not actually do the work until we figure out if it's necessary.

Nils, while Peter waits to hear back from Google, can you please ask a media engineer to verify how we can disable the OpenH264 download? What the user experience will be for users that try to access H.264 WebRTC media? Can we continue to use OpenH264 for users that have already downloaded it?

If we only have VP8/9 support, do we or sites need to change their WebRTC negotiation? Adam Stevenson says we may need reach out to some WebRTC sites there we know were broken by a recent OpenH264 issue on Fennec.

Flags: needinfo?(drno)

(In reply to Chris Peterson [:cpeterson] from comment #12)

Nils, while Peter waits to hear back from Google, can you please ask a media engineer to verify how we can disable the OpenH264 download?

Chris this code https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/toolkit/modules/GMPInstallManager.jsm#148
looks to me like setting 'media.gmp-gmpopenh264.autoupdate' to false should stop downloads of the OpenH264 plugin, right?

What the user experience will be for users that try to access H.264 WebRTC media?

For services with VP8/VP9 users will not notice any difference. For services which require H264 the call will fail to get establish. Error handling depends on the services.

Can we continue to use OpenH264 for users that have already downloaded it?

I think that is really only a Google Play store question, not a technical question. From the Firefox point of view the existing OpenH264 plugin on Android phones will continue to work. The only question is how we are going to handle updates if needed, e.g. security updates.

If we only have VP8/9 support, do we or sites need to change their WebRTC negotiation?

Byron verified already that we don't need to change anything on the Firefox side.

Adam Stevenson says we may need reach out to some WebRTC sites there we know were broken by a recent OpenH264 issue on Fennec.

We don't have a list of sites which would be affected by this. But even with the sites we know of it is not that these services have a choice to switch to something else. They are usually restricted by something in their system. So all we could do at this point is to give them a heads up that Firefox on Android is going to stop to work for them.

Flags: needinfo?(drno) → needinfo?(cpearce)

Flipping the prefs here [1] should disable OpenH264 downloads for Android - we used those prefs to disable OpenH264 for aarch64 windows temporarily. Flipping "media.gmp-gmpopenh264.enabled" to false will disable OpenH264 even if it is already downloaded.

[1] https://searchfox.org/mozilla-central/source/mobile/android/app/mobile.js#583

That would still allow the user to flip the prefs and get a download. To prevent that, we'd want to ask RelEng to update the Balrog rules to stop OpenH264 downloads for Android.

That would still allow the user to flip the prefs and get a download.

Isn't that what we want? Can we explore if this is acceptable?

(In reply to Dan Minor [:dminor] from comment #15)

That would still allow the user to flip the prefs and get a download. To prevent that, we'd want to ask RelEng to update the Balrog rules to stop OpenH264 downloads for Android.

That is an interesting point. I think the "autoupdate" pref I pointed at in comment #13 would allow us to keep the OpenH264 plugin active and usable on all installations which have downloaded the plugin already. I don't see any value in turning it off for them. So this might be something we would want to push out via Normandy to all Fennec users if Google insists on stopping the downloads across all versions right away.

But Dan you are right that "just" setting the "enabled" pref to false in a new upcoming Fennec version would be easier, as it would only affect new downloads of Fennec. And leave people with the option to potentially opt-in to downloading the plugin. But I have no idea how Google thinks about that.
A bad side effect would be that anyone who has for example Fennec 66 with OpenH264 downloaded already on its phone and then update to a version of Fennec with the "enabled" flag set to false, would suddenly loose OpenH264 functionality, although that is not what Google is asking for AFAIK.

It was just pointed out to me by RyanVM that we don't have Normandy available on Fennec. So we can not flip prefs in Fennec Release.

When exactly did the "30 days to fix this" clock start ticking? What deadline are we looking at here?

The clock was set on April 30. Conversations are underway with Google to extend that or, as I said above, for Google to grant us an exemption.

(In reply to Nils Ohlmeier [:drno] from comment #13)

Chris this code https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/toolkit/modules/GMPInstallManager.jsm#148
looks to me like setting 'media.gmp-gmpopenh264.autoupdate' to false should stop downloads of the OpenH264 plugin, right?

I have verified that in Firefox on Android setting media.gmp-gmpopenh264.autoupdate=false results in us not downloading OpenH264 if it's not already installed, and not uninstalling and not disabling OpenH264 if it is installed.

If we set media.gmp-gmpopenh264.autoupdate to false, there's no easily discoverable way for users to turn it on. The only way is to use about:config.

Could we prompt users to authorize the install of OpenH264, like we do for the Widevine CDM on Linux the first time the user tries to use WebRTC? Probably not within the 30 day window.

Changing the default value of the enabled pref to false seems like a reasonable option, as users can turn it on again.

Note we have code to send video decoding from WebRTC through playback's platform decoder architecture which works on Android, except on some handsets (notably the SGS8) the platform decoder outputs green frames. We don't have encoding support either, so it's not a complete solution yet. Hidden behind prefs media.navigator.mediadatadecoder_h264_enabled and media.navigator.mediadatadecoder_vpx_enabled.

Note for future testers; to cause a GMP update, reset media.gmp.gmp-gmpopenh264.lastUpdate and app.update.lastUpdateTime.auto-addon-background-update-timer and restart Firefox. Set media.gmp.log.dump=true and media.gmp.log.level=0, and run adb logcat | grep GMP to observe GMPProvider running. Toggling media.gmp-gmpopenh264.version uninstalls OpenH264.

Flags: needinfo?(cpearce)
Priority: -- → P1

My understanding:
Peter is working on G for an exception and/or clock extension.
We have our blunt instrument fix in hand: setting media.gmp-gmpopenh264.autoupdate to false. We can't do this via Normandy so we'd want to update Fennec in store with this config change before the clock runs out.
Long term, we still have an open question as to whether we should ask the user. Who would answer this?

Flags: needinfo?(abovens)

Hey Nils, I'd like to assign this bug to you to make sure the right solution is found and so it's clear who relman and other stakeholders should ask if they have questions. Thanks.

Assignee: nobody → drno

(In reply to David Bolter [:davidb] (NeedInfo me for attention) from comment #22)

My understanding:
Peter is working on G for an exception and/or clock extension.
We have our blunt instrument fix in hand: setting media.gmp-gmpopenh264.autoupdate to false. We can't do this via Normandy so we'd want to update Fennec in store with this config change before the clock runs out.

I think you are right in the sense that we should have a patch ready to be landed.

But since we can only revert this change via another Fennec update version I'm a little hesitant to land this pro-actively. So I would wait for Peter as long as we can.

Long term, we still have an open question as to whether we should ask the user. Who would answer this?

Isn't that a question Peter could also clarify when he is engaged with G?

Are there any further updates?

Flags: needinfo?(abovens)
Whiteboard: [geckoview:fenix:m5] → [geckoview:fenix:m5][bcs:p1]

Peter received an email which sounds like we are not going to get exemption. I'll try get this ready for the worst case scenario, which is landing the pref change in the attached patch on all Fennec branches.

Comment on attachment 9064497 [details]
Bug 1548679: disable future downloads of OpenH264 for Fennec. r=dminor

Beta/Release Uplift Approval Request

  • User impact if declined: Without this change Google is threatening to delist Fennec from the Android Playstore on 2019-05-30.
    If applied this patch will result in new Fennec users no longer being able to use H264 in WebRTC calls. But that is still better then not being able to use Fennec at all any more.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: - do a fresh installation of Fennec
  • open Fennec
  • leave the browser running for 15min (don't use it)
  • open about:addons
  • verify that "OpenH264 Video Codec provided by Cisco Systems, Inc." is not listed as available
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is only changing the preference which controls if the OpenH264 plugin gets downloaded or not.
  • String changes made/needed: N/A
Attachment #9064497 - Flags: approval-mozilla-release?
Attachment #9064497 - Flags: approval-mozilla-beta?
Flags: qe-verify+

I guess this is pretty hard to do but I am wondering what we should do with other stores where we publish Firefox (example: Samsung).

(In reply to Sylvestre Ledru [:sylvestre] from comment #29)

I guess this is pretty hard to do but I am wondering what we should do with other stores where we publish Firefox (example: Samsung).

Do the other stores have policies that prohibit downloading code from non-store servers? It's likely. We can either check or just wait for them to notify us.

OTOH, since the OpenH264 download is controlled by a pref, we would need separate APK builds or some run-time check if we wanted to download OpenH264 when Fennec/GeckoView is installed from other stores. Since other stores are uncommon, it's probably easiest to find a solution that compatible with the Play Store and use it everywhere.

Are you planning on landing this on trunk?

Flags: needinfo?(drno)
Summary: Stop downloading OpenH264 plugin on Android? → Stop downloading OpenH264 plugin on Android
Depends on: 1529082

(In reply to Julien Cristau [:jcristau] from comment #31)

Are you planning on landing this on trunk?

Yes I would like to, but it might create public notice. So the current plan is to wait with the landing in mozilla-central as late as possible.

  • revert the change if we get some form of extension from Google
  • or uplift to Beta and Release if we don't get an extension early enough
Flags: needinfo?(drno)

Nils, I think this is the right move. Need to be ready if we don't get that extension.

We have an extension of at least a week and perhaps 30 days. I will know more in the next 12-24 hours. Thus we do not need to land this code today or tomorrow! More details to follow.

Confirmed: our deadline is now June 30.

Comment on attachment 9064497 [details]
Bug 1548679: disable future downloads of OpenH264 for Fennec. r=dminor

Resetting the uplift flags as we currently don't plan to land and/or uplift this any more.

Attachment #9064497 - Flags: approval-mozilla-release?
Attachment #9064497 - Flags: approval-mozilla-beta?

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:drno, could you have a look please?
For more information, please visit auto_nag documentation.

Flags: needinfo?(drno)
Flags: needinfo?(drno)
Whiteboard: [geckoview:fenix:m5][bcs:p1] → [geckoview:fenix:m5][bcs:p1][no-nag]

We are still pursuing a conversation with the Google Play team about potential solutions, some of which do not require disabling the feature. Please stand by for further updates. :-)

It now appears that we need to ship this code. We are still talking with the Google Play team about exact timing and I am requesting a deadline extension so that we can release this in Firefox 68 rather than another interim release (67.0.3).

Currently it looks like we might want to completely disable OpenH264 for Fenix. Which is a different use case. So for that we probably want/need a different patch. My current thinking is to flip https://searchfox.org/mozilla-central/rev/c606cdd6d014fee4034da1702d484c0d41b604c9/mobile/android/app/mobile.js#582 to false. That should hide the OpenH264 plugin and prevent it from getting downloaded.

Stefan: how can change prefs for Fenix only (but not Fennec) and the other way around?

Flags: needinfo?(sarentz)
Attachment #9064497 - Attachment description: Bug 1548679: disable future downloads of OpenH264 on Android. r=dminor → Bug 1548679: disable future downloads of OpenH264 for Fennec. r=dminor

Depends on D30939

Clearing needinfo for Stefan, since Nils got an answer to his question on Slack.

68=affected because we'll need to uplift both patches to 68 Beta. Hopefully we won't need a Fennec 67.0.x dot release.

Flags: needinfo?(sarentz)
Attachment #9071671 - Attachment is obsolete: true

Comment on attachment 9064497 [details]
Bug 1548679: disable future downloads of OpenH264 for Fennec. r=dminor

Beta/Release Uplift Approval Request

  • User impact if declined: Without this change Google is threatening to delist Fennec from the Android Playstore. 
If applied this patch will result in new Fennec users no longer being able to use H264 in WebRTC calls. But that is still better then not being able to use Fennec at all any more.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: * do a fresh installation of Fennec - it is important that there isn't an existing user profile with the OpenH264 plugin in it already.
  • open Fennec
  • open about:addons
  • verify that "OpenH264 Video Codec provided by Cisco Systems, Inc." is not listed as available
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is only changing the preference which controls if the OpenH264 plugin gets downloaded or not.
  • String changes made/needed: N/A
Attachment #9064497 - Flags: approval-mozilla-beta?

Comment on attachment 9064497 [details]
Bug 1548679: disable future downloads of OpenH264 for Fennec. r=dminor

approved for 68.0b13

Attachment #9064497 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

Hello, I tried to verify this ticket based on comment 28 and 45 but the issue is still reproducible. The Open H264 plugin is still available on about:addons.

I tried multiple scenarios to be sure that the issue is still reproducible:

  • Let the app. in background for more than 15 min.;
  • Let the app opened and verify after 15 min.;
  • Open the app first time after 15 min.
  • Open the app and verify on the first minutes;

Devices:

  • Samsung Galaxy Tab A 6 (Android 5.1.1);
  • HTC Desire 820 (Android 6.0.1);
  • Nokia 6 (Android 7.1.1);
  • Xiaomi Mi 8 Lite (Android 8.1);
  • Samsung Galaxy Note 8 (Android 9);
  • Google Pixel (Android Q).

Builds:

  • Nightly 69.0a1 (2019-06-25) - treeherder;
  • Nightly 68.0a1 (2019-06-21) - Playstore;
  • Beta 68.0b13 - archive;

Additionally, I tried to play some H264 files using FF but I don't see any difference.
Due to my findings, I'll reopen the ticket and NI the assigned person to investigate my findings.

Status: RESOLVED → REOPENED
Flags: needinfo?(drno)
Resolution: FIXED → ---

I confirm that fresh installs of Firefox for Android Nightly and 68.0 Beta 13 are still downloading the OpenH.264 package. Sent an email to mreavy, Nils, jcristau and stpeter.

Debugging this on the desktop platform to help identify why the patch isn't working as expected:

  • Fresh build and profile (not strictly required).
  • Navigate to about:config and add + set media.gmp-gmpopenh264.autoupdate to false.
  • Also add + set media.gmp.log.level to 5, this helps log GMP update to the browser console for debugging.
  • Navigate to about:addons force and update check by clicking the drop down cog menu and selecting 'Check for updates'.
  • Browser console shows logs various logs with us updating openh264 (logs below have some lines dropped/are non exhaustive):
Toolkit.GMP	TRACE	GMPWrapper(gmp-gmpopenh264) findUpdates() - gmp-gmpopenh264 - reason=1
Toolkit.GMP	TRACE	GMPWrapper(gmp-gmpopenh264) findUpdates() - updateTask
Toolkit.GMP	INFO	GMPInstallManager._getURL Using url (with replacement): https://aus5.mozilla.org/update/3/GMP/69.0a1/20190626142154/WINNT_x86_64-msvc-x64/en-US/default/Windows_NT%2010.0.0.0.17763.557%20(x64)/default/default/update.xml
Toolkit.GMP	INFO	GMPAddon.constructor Created new addon: gmp-gmpopenh264 (isValid: true, isInstalled: false, hashFunction: sha512, hashValue: 06511f1f6c6d44d076b3c593528c26a602348d9c41689dbf5ff716b671c3ca5756b12cb2e5869f836dedce27b1a5cfe79b93c707fd01f8e84b620923bb61b5f1, size: 453023)
Toolkit.GMP	TRACE	GMPWrapper(gmp-gmpopenh264) findUpdates() - found update for gmp-gmpopenh264, installing
Toolkit.GMP	INFO	GMPDownloader install to directory path: gmp-gmpopenh264\1.8.1

To repeat this test with no h264 plugin you could blow away the directory it's installed to and repeat the above. However, even without blowing away that dir if a check for updates is done the logs will show a lot.

My expected behaviour here (correct me if I'm off mark) is that the updater shouldn't even be trying to see if there are updates for openh264: don't hit the balrog server and check for updates, don't do any of that process.

Going to dig a little more to see what's happening here. My current read is that the pref we're setting does not work how we think it should.

Hey Stephen, you may have touched some of this code ages ago and so might know something about it. Could you take a look and see?

Flags: needinfo?(spohl.mozilla.bugs)

I think the confusion here is that the plugin is listed in the Installed Plugins list in about:plugins, but isn't actually installed. You know it's installed if it has a valid version string in about:plugins. If it's not installed, the version field is "$version".

I tested Nightly on my Samsung Galaxy S6, it's working for me, using these STR:

  1. Uninstall Nightly.
  2. Go to play store, search for "Firefox Nightly", tap install.
  3. Open Firefox Nightly.
  4. Open about:config.
  5. Create a boolean pref media.gmp.log.dump with value True.
  6. Create an Integer pref media.gmp.log.level with value 0.
  7. Shutdown Firefox Nightly.
  8. On my desktop terminal, ensure my phone is connected to my USB cable, run adb logcat | grep GMP.
  9. Start Firefox Nightly.
  10. Wait, the logcat will eventually show a line "GMPInstallManager.simpleCheckAndInstall Auto-update is off for gmp-gmpopenh264, skipping check."
  11. Open about:plugins.
  12. Observe "openh264" is in the "installed plugins" list, but is listed with its version string as "$version".

Note the background updater runs 60 seconds after startup. So if you want the logging, you need to complete steps 3-7 in under 60 seconds, or the background updater will run before you have had a chance to restart and observe the logging.

I note that Nils see different results when he runs this in the emulator. I don't understand why that is.

I also tested Beta by manually uninstalling openh264 (toggle media.gmp-gmpopenh264.version to uninstall) and reseting media.gmp-manager.lastCheck, media.gmp.gmp-gmpopenh264.lastUpdate, and app.update.lastUpdateTime.auto-addon-background-update-timer, and restarting Firefox, and observing the logging saying we were skipping the openh264 download.

So as far as I can tell, we're seeing expected behaviour in Nightly and Beta with the patch. It's working, but the confusion here is caused by the misleading UI in about:plugins.

Talking with cpearce it appears that this is a UI problem. Open H264 is not downloaded but it still appears in the UI. The only way to notice this is that there is no version number. Vlad is this something that your team can solve?

Flags: needinfo?(vlad.baicu)
Flags: needinfo?(spohl.mozilla.bugs)

(In reply to Bryce Seager van Dyk (:bryce) from comment #52)

My expected behaviour here (correct me if I'm off mark) is that the updater shouldn't even be trying to see if there are updates for openh264: don't hit the balrog server and check for updates, don't do any of that process.

The logs I see on android are:

06-27 11:34:02.275 24693 24746 I Gecko   : 1561592042275	Toolkit.GMP	INFO	GMPInstallManager.simpleCheckAndInstall A version change occurred. Ignoring media.gmp-manager.lastCheck to check immediately for new or updated GMPs.
06-27 11:34:02.282 24693 24746 I Gecko   : 1561592042281	Toolkit.GMP	INFO	GMPInstallManager._getURL Using url: https://aus5.mozilla.org/update/3/GMP/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml
06-27 11:34:02.549 24693 24746 I Gecko   : 1561592042549	Toolkit.GMP	INFO	GMPInstallManager._getURL Using url (with replacement): https://aus5.mozilla.org/update/3/GMP/68.0a1/20190625170434/Android_aarch64-gcc3/en-US/nightly/Linux%2024/default/default/update.xml
06-27 11:34:03.053 24693 24746 I Gecko   : 1561592043053	Toolkit.GMP	INFO	GMPAddon.constructor Created new addon: gmp-gmpopenh264 (isValid: true, isInstalled: false, hashFunction: sha512, hashValue: 307d188876f3612a9168c0b4ed191db2132f2e3193bdd3024ce50adcb9c1e085ab43008531a25e93d570a377283336cda9bcd7609ee6b702c5292f12d20b616b, size: 557884)
06-27 11:34:03.059 24693 24746 I Gecko   : 1561592043059	Toolkit.GMP	INFO	GMPInstallManager.simpleCheckAndInstall Found 1 addons advertised.
06-27 11:34:03.062 24693 24746 I Gecko   : 1561592043062	Toolkit.GMP	INFO	GMPInstallManager.simpleCheckAndInstall Found addon: gmp-gmpopenh264 (isValid: true, isInstalled: false, hashFunction: sha512, hashValue: 307d188876f3612a9168c0b4ed191db2132f2e3193bdd3024ce50adcb9c1e085ab43008531a25e93d570a377283336cda9bcd7609ee6b702c5292f12d20b616b, size: 557884)
06-27 11:34:03.063 24693 24746 I Gecko   : 1561592043063	Toolkit.GMP	INFO	GMPInstallManager.simpleCheckAndInstall Auto-update is off for gmp-gmpopenh264, skipping check.
06-27 11:34:03.063 24693 24746 I Gecko   : 1561592043063	Toolkit.GMP	INFO	GMPInstallManager.simpleCheckAndInstall No new addons to install, returning
06-27 11:34:03.458 24693 24746 I Gecko   : 1561592043457	Toolkit.GMP	TRACE	GMPWrapper(gmp-gmpopenh264) findUpdates() - gmp-gmpopenh264 - reason=16
06-27 11:34:03.459 24693 24746 I Gecko   : 1561592043459	Toolkit.GMP	TRACE	GMPWrapper(gmp-gmpopenh264) findUpdates() - gmp-gmpopenh264 - last check was less then a day ago

So this indicates to me that we check for updates, and then filter on whether updates are disabled for the addons reported, rather than detecting that all addons are disabled, so we shouldn't check for updates.

Going to dig a little more to see what's happening here. My current read is that the pref we're setting does not work how we think it should.

Possibly the problem here is you manually checked for an update for the plugin? The pref disable auto updates, not manual updates.

(In reply to Chris Pearce [:cpearce (GMT+13)] from comment #56)

(In reply to Bryce Seager van Dyk (:bryce) from comment #52)

Going to dig a little more to see what's happening here. My current read is that the pref we're setting does not work how we think it should.

Possibly the problem here is you manually checked for an update for the plugin? The pref disable auto updates, not manual updates.

This theory is correct; we test the autoupdate pref here:
https://searchfox.org/mozilla-central/rev/06bd14ced96f25ff1dbd5352cb985fc0fa12a64e/toolkit/modules/GMPInstallManager.jsm#226

And that's on the simpleCheckAndInstall path, which happens 60s after startup:
https://searchfox.org/mozilla-central/rev/06bd14ced96f25ff1dbd5352cb985fc0fa12a64e/browser/components/BrowserGlue.jsm#1854

So the manual "check for updates for this plugin" path you're probably taking will bypass this check.

(In reply to Chris Pearce [:cpearce (GMT+13)] from comment #57)

snip

So the manual "check for updates for this plugin" path you're probably taking will bypass this check.

Thanks for clarifying that. I'm surprised that the manual path also works if I set media.gmp-gmpopenh264.enabled to false, but that doesn't seem like an immediate concern.

It looks to me like on Android you cannot kick off the manual update. If there's no other paths to triggering that then we should be good outside of users reverting the pref. I'm not sure I saw an answer to the question on if that would be considered acceptable.

So I just verified once more on OSX:

  • start with a fresh user profile
  • set the "media.gmp-gmpopenh264.autoupdate" to false
  • restart the browser
  • open "about:addons" and watch the yellow bar below the Widevine plugin dis-appear as it gets downloaded
  • the yellow bar for the OpenH264 plugin stays as it doesn't get downloaded

As Chris indicated earlier I had non-consistent results on Android. From a local build on Linux running in the emulator I saw the plugin getting downloaded even with the autoupdate pref set to false. But with the emulator and a local build on OSX the plugin did not get downloaded. Also on a Moto G5 following the steps from comment #54 Fennec did not download the plugin.

(In reply to Bryce Seager van Dyk (:bryce) from comment #58)

It looks to me like on Android you cannot kick off the manual update. If there's no other paths to triggering that then we should be good outside of users reverting the pref. I'm not sure I saw an answer to the question on if that would be considered acceptable.

Since we are only changing user prefs I think we can't prevent advanced users from flipping the prefs back. I'm assuming this should be acceptable. If not we could look later into how we can turn this into a non-reversable change on the 68 ESR branch.

Flags: needinfo?(drno)

It's been mentioned above, but I believe if we need a fall back we could stop shipping via Balrog if needed (though I have not verified this).

Based on the collected data and observations here it seems highly likely that my not precise testing instructions in comment #28 combined with the not-perfect UI after flipping the pref might have caused confusion.

Stefan could I ask you to verify once more with these steps (a simplified version from comment #54):

  1. Uninstall Nightly.
  2. Go to play store, search for "Firefox Nightly", tap install.
  3. Open Firefox Nightly.
  4. Open about:plugins.
  5. Wait for 5min
  6. Observe "openh264" is in the "installed plugins" list, but is listed with its version string as "$version" and does NOT show as version 1.8.1

I created this super simple test page which should allow you to verify if H264 in WebRTC still works or not:
https://mozilla.github.io/webrtc-landing/pc_test_no_h264.html
After pressing the "Test" button you should see "H.264 is NOT supported!" on Fennec now (on desktop you should see "YES H.264 is supported!" instead).

Flags: needinfo?(stefan.deiac)
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED

(resolved this again since per comment 62 it sounds like the verification instructions were wrong but the patch is OK; pending reverification)

Hello, I retested using the steps from comment 62 and I can confirm that the version string is '$version' and does not show as version 1.8.1.

Devices:

  • Nexus 5 (Android 6.0.1);
  • Nokia 6 (Android 7.1.1);
  • LG G7 fit (Android 8.1);
  • Samsung Galaxy S8 (Android 9);
  • Google Pixel (Android Q).

Builds:

  • Nightly 68.0a1 (2019-06-25);
  • Beta 68.0b13.

Additionally, I tested with the link from the comment 62 and I can confirm that the H.264 is not supported.
I'll make a new bug for the fact that the Open H264 is still presented on the about:addons.

Flags: qe-verify+
Flags: needinfo?(stefan.deiac)
See Also: → 1561844

Sure, the fix appears to be fairly simple. Tracking the progress in bug 1561844

Flags: needinfo?(vlad.baicu)
Depends on: 1561844

Now that this has been resolved, can we drop the Mozilla Confidential flag?

(In reply to Dan Callahan [:callahad] from comment #66)

Now that this has been resolved, can we drop the Mozilla Confidential flag?

As the incident commander, I approve of opening up this bug.

Group: mozilla-employee-confidential

Added a note to Firefox 68 for developers as well as to the Codecs used by WebRTC article about this.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: