1044268 - Ability to turn off H.264 downloads in the field if there are problems

Status: RESOLVED WORKSFORME

(Core :: WebRTC, defect)

Description

[Maire Reavy [:mreavy]]

I know I'm not filing this in the right component, but we want the ability to turn off H.264 downloads if there are problems in the field.  We may be able to do this at the server end alone.

Comment 1

[Nils Ohlmeier [:drno]]

I think here are two things with some overlap mixed:
1) The request for a user pref which allows certain users or entities to opt for not even downloading the binary code of the plugin to their machines.
2) A way to prevent the download of the plugin if it should be too unstable for a release.

Number 1 should be implemented in any case. Purely as a curtsey to users who don't want the plugin for whatever reason.
I see the support for #1 also as a good way to achieve #2. Number 2 could also be achieved by having the plugin download server deliver some information which prevents Firefox from downloading. But that would mean all users are prevented from using the plugin, and it would be hard to change that decision later as as soon as we would let the server point to the correct download all Firefox would start to fetch it. Option #1 could for example be used to have one Firefox release version not download the plugin, but allow it by default for a later release (without affecting the older versions).

Comment 2

[Robert Kaiser]

I agree that one pref will help both what comment #0 says and what some FLOSS purists are worried about (not wanting any such binary "tainting" their computer).

Comment 3

[Nils Ohlmeier [:drno]]

Noticed that if you set the gmp server url to "" this seems to prevent the plugin download. Not a nice solution.
Brian, is setting the URL to "" a "legit" way to prevent the plugin download? Is there a better way?

Comment 4

[Brian R. Bondy [:bbondy]]

No there's no explicit way to turn it off currently, setting the URL to an invalid URL works though.

Do we just want a pref for enabled/disabled for this bug?

Note that we do have a way to turn off updates already if there are problems, but only globally from the releng side. Just stop offering the update.

Comment 5

[Brian R. Bondy [:bbondy]]

And only in about:config?

Comment 6

[Georg Fritzsche [:gfritzsche]]

(In reply to Nils Ohlmeier [:drno] from comment #1)
> I think here are two things with some overlap mixed:
> 1) The request for a user pref which allows certain users or entities to opt
> for not even downloading the binary code of the plugin to their machines.

We do have an option to turn off auto updates in the detail view of the OpenH264 plugin entry.
It looks like we don't honor the backing pref (media.gmp-gmpopenh264.autoupdate) for the initial download check though.

Filed bug 1046644 on this.

Comment 7

[Georg Fritzsche [:gfritzsche]]

(In reply to Nils Ohlmeier [:drno] from comment #1)
> I think here are two things with some overlap mixed:
> 1) The request for a user pref which allows certain users or entities to opt
> for not even downloading the binary code of the plugin to their machines.
> 2) A way to prevent the download of the plugin if it should be too unstable
> for a release.

We have 1) resolved via bug 1046644.
What's the goal for 2)? Do we want to avoid downloads (sounds like a server-side issue on our end) or block plugins in the wild (would mean we need to implement blocklisting for GMP)?

Comment 8

[Maire Reavy [:mreavy]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #7)
> (In reply to Nils Ohlmeier [:drno] from comment #1)
> > 2) A way to prevent the download of the plugin if it should be too unstable
> > for a release.
> 
> What's the goal for 2)? Do we want to avoid downloads (sounds like a
> server-side issue on our end) or block plugins in the wild (would mean we
> need to implement blocklisting for GMP)?

I believe the goal for 2) for OpenH264 in Fx 33 can and would be addressed on the server side.

Comment 9

[Benjamin Smedberg]

We also have media.gmp-gmpopenh264.provider.enabled which we can change via hotfix. AIUI disabling this should completely disable activating the OpenH264 plugin, although it still might be downloaded. Georg can you confirm?

We can control downloads by turning OpenH264 off on AUS.

So assuming my statements are correct, I don't think there's anything to do on this bug.

Comment 10

[Georg Fritzsche [:gfritzsche]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #9)
> We also have media.gmp-gmpopenh264.provider.enabled which we can change via
> hotfix. AIUI disabling this should completely disable activating the
> OpenH264 plugin, although it still might be downloaded. Georg can you
> confirm?

We can do proper disabling via the following prefs:
media.gmp-gmpopenh264.autoupdate;false
media.gmp-gmpopenh264.enabled;false
media.gmp-gmpopenh264.provider.enabled;false

Comment 11

[Richard Z.]

(In reply to Georg Fritzsche [away Nov 15 - Nov 30] [:gfritzsche] from comment #10)
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #9)
> > We also have media.gmp-gmpopenh264.provider.enabled which we can change via
> > hotfix. AIUI disabling this should completely disable activating the
> > OpenH264 plugin, although it still might be downloaded. Georg can you
> > confirm?
> 
> We can do proper disabling via the following prefs:
> media.gmp-gmpopenh264.autoupdate;false
> media.gmp-gmpopenh264.enabled;false
> media.gmp-gmpopenh264.provider.enabled;false

how is a user expected to do this. about:config works only after startup which is too late to prevent download.

Comment 12

[Richard Z.]

The binary is also downloaded in safe mode in a freshly created profile. I don't think this is expected.

https://bugzilla.mozilla.org/show_bug.cgi?id=1105990

Comment 13

[Benjamin Smedberg]

This bug is not about users disabling download. It has to do with Mozilla disabling download via either hotfix or update. Neither is this bug about safe mode.