1007694 - [UX] Decide how to expose the option to disable openh264

Status: VERIFIED FIXED

(Firefox :: Settings UI, enhancement)

Description

[Benjamin Smedberg]

We will be downloading and using the Cisco openh264 binary automatically in Firefox. This will primarily support webrtc calling at this point but may also be useful for various other H.264 encoding activities. Because this is not Mozilla code, we want to give users the ability to disable it if that's important to them.

I suggest that we should show this as an automatically activated plugin in the addon manager "Plugins" pane, but I'd like somebody from UX to confirm that decision or provide an alternate UI for disabling this plugin.

Comment 1

[Benjamin Smedberg]

Came up during discussion, we may also need to decide how to expose updates if the user has automatic updates disabled. I don't know whether addon automatic updates have separate preferences. Irving do you know how that works in the UI?

Comment 2

[Cody Crews]

I'm always weary of any plugin that's automatically installed or enabled.  It's like saying hey here's a binary library to fuzz/attack that will be known to be there and waiting to be attacked.  It's something akin to the constant set of 'default configuration' bugs.

Comment 3

[Cody Crews]

I realized that could be even worse with full access to the source since it will be open source.  =/ maybe I'm to paranoid about stuff like that though.

Comment 4

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #0)
> I suggest that we should show this as an automatically activated plugin in
> the addon manager "Plugins" pane, but I'd like somebody from UX to confirm
> that decision or provide an alternate UI for disabling this plugin.

That's a very sensible choice since the vast majority of users won't know what openh264 is anyway if we put it in a more prominent place.
I don't know how (and if at all) plugins auto-update though. I couldn't find any preferences for that. Or is it automatically tied to the auto-update preference for the browser itself?
From the top of my head, a good way would be to show an info bar when an update is available and auto-updates are off.

Comment 5

[:Irving Reid (No longer working on Firefox)]

Are we planning to distribute this as a (legacy) NPAPI plugin, or as an XPI extension? Firefox doesn't auto-update NPAPI plugins; the plugin itself is responsible for managing that. As Philipp noted, there's no plugin update UI in the browser.

Another point: extensions (and, presumably, plugins) distributed as part of the Firefox installer typically land in the application directory, which we don't have permission to write during normal browser operation. Can we live with just using application updates to replace the plugin if necessary, rather than having a separate update channel for it?

Comment 6

[Benjamin Smedberg]

This is neither an NPAPI plugin nor a Firefox extension: it is a new kind of thing. We must download this from Cisco, but we intend to install and update this Cisco software automatically on Firefox launch. For that reason it will live in the profile not the application directory.

bug 1009816 has some requirements/details about the actual download/update process.

Comment 7

[Cody Crews]

I know I'm overly paranoid most definitely but I just have to stress what I said before.  I'm probably just grinding my wheels though as I'm sure this library has already been targeting plenty.  Sorry for getting involved in a UX bug guys, but please make it obvious how to disable this when it lands because I'll be one of the first to do so.

Comment 8

[Cody Crews]

^^ should be targeted.  Going to have to one day get my mind and fingers on the same page someday, they tend to do what they want ;)

Comment 9

[:Irving Reid (No longer working on Firefox)]

The 'extension' category in about:addons already has most (if not all) of the features you need:
 * enable/disable automatic updates either per-addon or globally
 * enable/disable the add-on itself
 * manually start update

Whether that provides the visibility and UX we want is certainly open to discussion, but the knobs and buttons exist.

Comment 10

[Benjamin Smedberg]

I suspect that we'd like to expose this (and future DRM plugins) in the "plugins" category in the UI. Can we control whether the check-for-updates UI appears on a per-item basis? I see that the gear icon is visible in both views.

Comment 11

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Attachment: Mockup

Here's a mockup of how I could imagine this. The update behavior for this specific plugin could then be controlled in the preferences.

Not sure if we really need the »More« link on this item.

Benjamin, does this cover all the use cases we have here?

Comment 12

[Benjamin Smedberg]

In extensions there often isn't a "Preferences" button, just the single "Enable" or "Disable" button, and "Find Updates" in on a context menu. Is it ok to just reuse that model?

Comment 13

[:Irving Reid (No longer working on Firefox)]

Note that even when viewing the 'Plugins' section, the commands in the "gear icon" menu actually apply mostly to 'extensions' and 'appearance' items, because those are the ones we (currently) know how to update automatically. I don't have a problem with extending that to also update plugins, where possible.

(as an aside, i'm tempted to file a bug to add the third-party update URL to the 'more' page for other plugins when we know it, to help users update them when we can't do it automatically)

For extensions, we normally display the same content under the 'more' link and the 'preferences' button; we show the 'preferences' button when the extension's manifest declares that it has some user-adjustable settings (Whimsy Pro is an example of this). However, it's also possible for the extension to completely override the 'preferences' page (JSONView is an example).

For extensions, the 'more' page (and 'preferences', if the extension hasn't overridden it) is where the user can control the per-addon automatic update behaviour.

Comment 14

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #12)
> In extensions there often isn't a "Preferences" button, just the single
> "Enable" or "Disable" button, and "Find Updates" in on a context menu. Is it
> ok to just reuse that model?

We could. I was under the assumption that we need preferences for enabling/disabling automatic updates for this plugin, in which case a preferences screen makes sense. If that is not the case, we can get rid of the prefs screen and use the model you proposed. I don't know about the security implications here, so I'll defer to your judgement here.

So this should be the complete list of options we want to give the user for the Openh264 plugin:
- Activate
- Deactivate
- Click to play
- Search for updates
- Auto-update (yes/no/default)?

(In reply to :Irving Reid from comment #13)
> Note that even when viewing the 'Plugins' section, the commands in the "gear
> icon" menu actually apply mostly to 'extensions' and 'appearance' items,
> because those are the ones we (currently) know how to update automatically.
> I don't have a problem with extending that to also update plugins, where
> possible.

That sounds sensible. I am a bit worried though that we might imply auto-updating behavior where none exists. Anyway that is material for a separate bug.


> (as an aside, i'm tempted to file a bug to add the third-party update URL to
> the 'more' page for other plugins when we know it, to help users update them
> when we can't do it automatically)

Yes, please :)

Comment 15

[Cody Crews]

This sounds perfect to me as I have said I'm definitely one of the first people going to disable this ASAP.  Ill only enabled for webRTC and such and then disable again immediately.

Comment 16

[Benjamin Smedberg]

> We could. I was under the assumption that we need preferences for
> enabling/disabling automatic updates for this plugin, in which case a
> preferences screen makes sense.

Well, we have the screen in general, but only available via the context menu. If it's ok I'd like to stay consistent with other addons.

> So this should be the complete list of options we want to give the user for
> the Openh264 plugin:
> - Activate
> - Deactivate



> - Click to play

I don't think we intend to build a per-domain click-to-play for this, so this is not an option.

> - Search for updates
> - Auto-update (yes/no/default)?

Right.

Comment 17

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Attachment: Mockup v2

I'd rather keep the »Preferences«-button as a redundant way to enter the plugin settings. Many extensions use it like this (»Preferences«, »More« and the context menu entry lead to the same page.
The fact that openh264 has its own auto-update options (in contrast to the other plugins where the »More«-page doesn't provide a lot of functionality) justifies such a deviation.

Here's an updated version of the mockup which includes the context menu.
The dropdown on the right (»Always activate«) ommits the »Ask to activate« option.
The settings for auto-updating are in the preferences (following the logic of extensions).
»More«, »Preferences« and »Show more Information« lead to the same screen.

Comment 18

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Marking as fixed since there seem to be no further objectsion

Comment 19

[Georg Fritzsche [:gfritzsche]]

Philipp, per bug 1009909, comment 11, we want to show this plugin entry even if the plugin is not installed (e.g. still downloading or was user-removed).
What should the look/behavior be here?

Comment 20

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Georg Fritzsche [:gfritzsche] from comment #19)
> Philipp, per bug 1009909, comment 11, we want to show this plugin entry even
> if the plugin is not installed (e.g. still downloading or was user-removed).
> What should the look/behavior be here?

I answered in that bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1009909#c12)