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

RESOLVED WORKSFORME

Status

()

Core
WebRTC
RESOLVED WORKSFORME
4 years ago
3 years ago

People

(Reporter: mreavy, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

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.
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

4 years ago
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).
(Reporter)

Updated

4 years ago
Blocks: 948160
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?
Flags: needinfo?(netzen)
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.
Flags: needinfo?(netzen)
And only in about:config?
(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.

Updated

4 years ago
Flags: firefox-backlog+
Flags: needinfo?(gavin.sharp)

Updated

4 years ago
Points: --- → 3
QA Whiteboard: [qa+]
(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)?
(Reporter)

Comment 8

4 years ago
(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.
Flags: firefox-backlog+
Flags: needinfo?(gavin.sharp)

Comment 9

4 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(georg.fritzsche)
Resolution: --- → WORKSFORME
(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
Flags: needinfo?(georg.fritzsche)

Comment 11

3 years ago
(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

3 years ago
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

Updated

3 years ago
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 13

3 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.