932854 - Consider showing a notification bar for hidden plugins

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Benjamin Smedberg]

I think we need to consider showing a notification bar for hidden plugins. The current icon is not discoverable enough for users on some important banking sites. Here are the reasons I think we should prefer a notification bar instead of an auto-popup doorhanger, whether it stays on the page permanently or temporarily:

* when we had the auto-popup doorhanger, users had two opposite complaints: that it would pop up but interacting with the page would immediately dismiss it; and that they wanted to stop it from popping up but there wasn't any way to do that
* Users who are not paying attention when the page is loading may not see a temporary popup.
* I'm willing to bet that somebody could clickjack a popup.

I have a patch which shows a notification bar when plugins are hidden. The close button on the notification bar will close it permanently for that site.

Comment 1

[Benjamin Smedberg]

Attachment: Show a notification bar when a plugin is hidden. Explicitly closing the notification bar will hide it permanently for that site. r?jaws ui-r?madhav/lco

Comment 2

[Benjamin Smedberg]

Comment on attachment 824708 [details] [diff] [review]
Show a notification bar when a plugin is hidden. Explicitly closing the notification bar will hide it permanently for that site. r?jaws ui-r?madhav/lco

It seems I can only mark ui-review for a single person. lco your review is also desired!

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> It seems I can only mark ui-review for a single person. lco your review is
> also desired!

http://logbot.glob.com.au/?c=mozilla%23developers&s=23+Sep+2013&e=23+Sep+2013&h=jaws#c766579

Comment 4

[Benjamin Smedberg]

Comment on attachment 824708 [details] [diff] [review]
Show a notification bar when a plugin is hidden. Explicitly closing the notification bar will hide it permanently for that site. r?jaws ui-r?madhav/lco

Cancelling review: some bugs and lco is tweaking the design more than a little.

Comment 5

[John Doe]

Are you planning to keep the current navbar icon?
If you do, please consider having a pref to disable the notification bar.

Comment 6

[Benjamin Smedberg]

Attachment: Checkpoint, non-working prototype.

When a site uses a hidden plugin, show a version of the in-content plugin UI at the top of the page for discoverability. It's cute that we can reuse the in-content binding for this, but it's also gotten poor reviews from the uifolk, so I'm just going to leave it here as a checkpoint and go back to a more normal button approach.

Comment 7

[Benjamin Smedberg]

Attachment: when a site uses a hidden plugin, show a notification bar to aid discoverability.

This (part A) produces a notification bar which uses the info/grey styling in all cases, and the only difference between a vulnerable and normal plugin is the icon. It is not clear yet whether the vulnerable plugin should be restyled to have the stripy background or the no-entry icon of the in-content UI

I will be preparing some screenshots and a try build, although the current UI is a boring as it sounds.

Comment 8

[Benjamin Smedberg]

Try builds will be at https://tbpl.mozilla.org/?tree=Try&rev=4ad590b08e56

Comment 9

[Benjamin Smedberg]

Attachment: Screenshot from 2013-11-05 18:31:14.png

Hidden non-vulnerable screenshot.

Comment 10

[Benjamin Smedberg]

Attachment: hidden single vulnerable plugin

Comment 11

[Benjamin Smedberg]

Attachment: hidden multi-vulnerable

Comment 12

[Benjamin Smedberg]

Oh also! This doesn't implement the link that was in the screenshots. I can do that, although I'll have to modify the notification binding a bit (Enn helped me figure out what the API should be). I'd like to know whether to implement the link.

Comment 13

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 827663 [details] [diff] [review]
when a site uses a hidden plugin, show a notification bar to aid discoverability.

Review of attachment 827663 [details] [diff] [review]:
-----------------------------------------------------------------

I have two issues with the patch for this bug:

1) The screenshots here don't make much sense to me.

The text in the notification bar for the multiple plugin case says "Allow example.com to run plugins? [Block plugins] [Options]". The problem that we have today is that users who need to run the plugins aren't finding out how to do so.

So why are we giving such huge affordance towards blocking the plugins instead of running the plugins? Secondly, it seems that we are posing a question but visibly only providing one potential answer and hiding the other choices behind the "Options" button.

2) The purpose of this bug as I understand it is to introduce a notification bar for hidden plugins because we are finding that users are having a hard time "fixing" the website they are on when we block a hidden plugin. One may interpret this as that users are having a hard time learning/finding the plugin icon in the location bar.

If the user chooses to "Block Now" and then later regrets their decision, they won't have a path towards fixing their mistake because the notification bar won't reappear. Since we don't expect them to have figured out the plugin icon in the location bar, they won't have any recourse until the permission expires.

Comment 14

[Richard Maher]

(In reply to Jared Wein [:jaws] from comment #13)
> Comment on attachment 827663 [details] [diff] [review]
Lots of good stuff.

Jared please continue to bring your [not so]common-sense to the fore and challenge the dogma-driven hatred for plugins. 

Ben will not be allowed to Fahrenheit-451 Applets. Well done that man!

Cheers Richard Maher

Comment 15

[Jared Wein [:jaws] (please needinfo? me)]

How about the following?

Allow example.com to run plugins? [Allow now] [Dismiss] [Options]

Where [Options] opens the doorhanger and allows the user to choose "Block Now", and [Dismiss] simply dismisses the notification bar but reloading the page will reshow the notification bar.

This seems clearer to me because the plugins are blocked by default, so choosing "Block Now" in this state seems redundant. The actions that a user can take here are basically 1) stop blocking the plugin; 2) don't bother me with this notification; 3) don't bother me with this notification now and in the future.

Comment 16

[Larissa Co [:lco]]

Bsmedberg, thanks for the screenshots, and Jaws, for the suggestions. Before we go in too deep here, I wanted to step back and explain the goals for the design of the infobar and our current restrictions.

To be clear, we're not aiming for the perfect design; we're aiming for something that is acceptable in FF26 and does not harm our users (whether we want to push back to FF27 is a different matter that's out of scope for discussion in this bug). Here's a concept that shorlander worked on which is closer to our ideal design: http://cl.ly/image/3R0w221e3z1e/o

In adding the infobar, we are trying to accomplish two goals:

1. Make the user's options apparent and clear to him/her without being too obtrusive
2. Direct the user to what we think is the "best", safe choice.

Goal #1:

Because just having the icon in the URL bar wasn't discoverable, it wasn't apparent to the user whether he had choices at all when it comes to hidden plugins. After some discussion on the design approach, we decided to go with an infobar. Like all of the other suggestions, there are some downsides to this approach, but we chose it because it's easily visible to the user without being obtrusive to their task. 

I also agree that the current strings in Ben's screenshots can be improved upon because they still don't communicate the user's choices clearly. "Block Plugin" is confusing because the plugin IS already being blocked; the text we initially wanted was "Continue Blocking". We also all agree that "Options" is a terrible name, and doesn't truly describe the user's choice. However, one of the constraints we are working with is shipping these UI changes in FF26. This severely limits our string options because we can't propose any new strings.

I like Jaws' suggestion of replacing "Options" with "Allow" since it doesn't require us to add any new strings. We can't do much about "Continue Blocking", but I'm ok keeping it in for now, and iterating in the next release.

---

Goal #2:

For vulnerable plugins, the "best", safe choice we can give the user is to block the plugin automatically and emphasize that default. I know there are many cases where a knowledgeable user (or even just one willing to take the risk) should be allowed to choose to have the plugin run. But I want to increase the likelihood that the user knows what he's choosing, not just accidentally clicking a button. This is why we introduced the "Block Plugins" button; I want to increase the cognitive friction for users who want to enable a potentially dangerous plugin. I also want the user to understand that allowing a plugin is not his only choice.

Again, Jaws' suggestion of "Allow" to replace "Options" is fine here, because clicking that button doesn't automatically enable the plugin, but rather, opens the doorhanger with the user's choices. Therefore, this is a higher friction, but still discoverable path.

For regular plugins, the "best" choice is a different matter, because we have less confidence in how unsafe the plugin really is. Thus, we err on the side of assuming that it's safe to run the plugin, if the user knows what it is. If possible, I would actually prefer providing the "Allow Now" and "Allow and Remember" choices in the infobar, rather than than the "Block Plugin" button that's currently in the screenshot.

---

Again, I don't think the screenshots that Ben has proposed amount to the best solution. I know there are many good ideas, and I don't want to lose them. But I also want to convey the design choices we had to make given the restrictions we had so that we can move forward with the implementation.

Comment 17

[Jared Wein [:jaws] (please needinfo? me)]

The "Allow Now" and "Allow and Remember" strings are available in Beta. I'm not sure why we're trying work around using them in the infobar?

At the risk of sounding like a curmudgeon, it seems we are settling for a lower potential solution when a better solution is available.

Comment 18

[Larissa Co [:lco]]

(In reply to Jared Wein [:jaws] from comment #17)
> The "Allow Now" and "Allow and Remember" strings are available in Beta. I'm
> not sure why we're trying work around using them in the infobar?
> 
> At the risk of sounding like a curmudgeon, it seems we are settling for a
> lower potential solution when a better solution is available.

I don't think you're being curmudgeonly :) My suggestion as well would be:

For the vulnerable plugins case -- use "Block Plugin" and "Allow"
For the regular plugins case -- use "Allow and Remember" and "Allow Now"

Comment 19

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 827663 [details] [diff] [review]
when a site uses a hidden plugin, show a notification bar to aid discoverability.

I believe this was sorted out by bsmedberg/lco/jaws/madhava elsewhere and a new patch is coming?

Comment 20

[Benjamin Smedberg]

Attachment: when a site uses a hidden plugin, show a notification bar to aid discoverability. This patch, suitable for trunk and branch, uses existing strings which are not ideal.

Comment 21

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 829764 [details] [diff] [review]
when a site uses a hidden plugin, show a notification bar to aid discoverability. This patch, suitable for trunk and branch, uses existing strings which are not ideal.

Review of attachment 829764 [details] [diff] [review]:
-----------------------------------------------------------------

r=me but I would very much prefer to not introduce another !important here if it is not really necessary.

::: browser/themes/shared/plugin-doorhanger.inc.css
@@ +60,5 @@
> +  color: white;
> +}
> +
> +notification.pluginVulnerable .messageImage {
> +  list-style-image: url("chrome://browser/skin/notification-pluginBlocked.png") !important;

Why is the !important needed here? The tagname + 2 class selectors should put the specificity higher than the class + attribute selectors that are used for the |.messageImage[value="plugin-hidden"]| selector above.

Comment 22

[Benjamin Smedberg]

Attachment: Fix tests to avoid infobar in chrome tests

Comment 23

[Georg Fritzsche [:gfritzsche]]

Comment on attachment 830834 [details] [diff] [review]
Fix tests to avoid infobar in chrome tests

Review of attachment 830834 [details] [diff] [review]:
-----------------------------------------------------------------

This looks good to me.

Comment 24

[Benjamin Smedberg]

Attachment: Fix test_bug391728.html

I hate tests with side effects. I also hate the mochitest chrome harness.

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Backed out for Windows mochitest-other crashes.
https://hg.mozilla.org/integration/fx-team/rev/5fa603642231

https://tbpl.mozilla.org/php/getParsedLog.php?id=30490234&tree=Fx-Team

Comment 26

[Benjamin Smedberg]

Attachment: Hacky-fix-test: forcibly remove infobar in test_keycodes.xul

Comment 27

[Benjamin Smedberg]

I have a bunch of followups to file around tests that are doing variously stupid things, to pay down some technical debt.

Comment 28

[Benjamin Smedberg]

Attachment: telemetry - add telemetry for showing the plugin infobar and its two buttons

Comment 29

[Benjamin Smedberg]

Attachment: trunk-only patch to use new strings for the buttons, r?jaws

Comment 30

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/be954182277a
https://hg.mozilla.org/mozilla-central/rev/aafde14ba277
https://hg.mozilla.org/mozilla-central/rev/c09869a04882

Comment 31

[Benjamin Smedberg]

reopening for the last two patches.

Comment 32

[Benjamin Smedberg]

Comment on attachment 829764 [details] [diff] [review]
when a site uses a hidden plugin, show a notification bar to aid discoverability. This patch, suitable for trunk and branch, uses existing strings which are not ideal.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): CtP-by-default made this more urgent, but it also affects existing users who have out-of-date Java or Flash.
User impact if declined: We cannot turn on the java block by default
Testing completed (on m-c, etc.): landed in nightly
Risk to taking this patch (and alternatives if risky): risk is localized to the CtP code, so targeted testing should show any issues. Heavyweight themes would also need some updates to style the icons properly, but wouldn't cause breaking changes.
String or IDL/UUID changes made by this patch: none

Comment 33

[Benjamin Smedberg]

https://hg.mozilla.org/integration/fx-team/rev/6ce923a22a9e (telemetry)
https://hg.mozilla.org/integration/fx-team/rev/1458d327affd (trunk-only strings)

Comment 35

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/6ce923a22a9e
https://hg.mozilla.org/mozilla-central/rev/1458d327affd

Comment 37

[Benjamin Smedberg]

Checkin-needed to uplift the following 4 csets to the branches:

https://hg.mozilla.org/mozilla-central/rev/be954182277a
https://hg.mozilla.org/mozilla-central/rev/aafde14ba277
https://hg.mozilla.org/mozilla-central/rev/c09869a04882
https://hg.mozilla.org/integration/fx-team/rev/6ce923a22a9e

The first will require a browser/base/content/tests/general rename, the rest should apply straight. If there are any issues I'll deal with it myself in the morning.

Comment 38

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/b1a341fb814f
https://hg.mozilla.org/releases/mozilla-aurora/rev/598daa4e76e1
https://hg.mozilla.org/releases/mozilla-aurora/rev/f3a99bcfe01b
https://hg.mozilla.org/releases/mozilla-aurora/rev/97325de07f00

https://hg.mozilla.org/releases/mozilla-beta/rev/02d3ec08c22d
https://hg.mozilla.org/releases/mozilla-beta/rev/76fc8e53c514
https://hg.mozilla.org/releases/mozilla-beta/rev/61fc6330e610
https://hg.mozilla.org/releases/mozilla-beta/rev/adb1127cd412

Comment 39

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/02d3ec08c22d
https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/76fc8e53c514
https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/61fc6330e610
https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/adb1127cd412

Comment 40

[Manuela Muntean [Away]]

Attachment: 26 beta 7_screenshot.png

Verified as fixed with Firefox 26 beta 7 (build ID: 20131122094025) on: Win 7 64-bit, XP 32-bit, Mac OS X 10.7 and Ubuntu 12.04 32-bit.

The notification bar attached in the screenshot is visible. Tested with:

http://benjamin.smedbergs.us/tests/ctptests/flash-hidden.html
http://benjamin.smedbergs.us/tests/ctptests/javaflash-hidden.html
http://benjamin.smedbergs.us/tests/ctptests/java-hidden.html
http://www.drive.google.com
https://www.alipay.com

I assume that after clicking the "Block Plugin" button from the notification bar and then restarting the browser, it's expected for the notification bar to not appear anymore.

Comment 41

[Georg Fritzsche [:gfritzsche]]

(In reply to Manuela Muntean [:Manuela] [QA] from comment #40)
> I assume that after clicking the "Block Plugin" button from the notification
> bar and then restarting the browser, it's expected for the notification bar
> to not appear anymore.

Yes, that's expected. If needed for testing you can reset this as in bug 941449, comment 13 & 14.

Comment 42

[David Barker]

It would be useful if this could be a configurable option. If you operate in a disabled-by-default mode, the bar seems to "nag" you to turn on plugins. For 90% of the sites I visit, I don't want to enable any plugins. On the rare (10%) exceptions, I'd rather manually enable the plugin by clicking the disabled element (using https://addons.mozilla.org/en-US/firefox/addon/click-to-play-per-element/?src=api as devs have disabled per-element click-to-play) or by clicking the icon on the left of the address bar.

Could we consider making this an about:config option or a preference?

Comment 43

[Benjamin Smedberg]

The "Continue Blocking" button will hide the infobar on that site permanently. See also bug 942461.

Comment 44

[David Barker]

Thanks :bsmedberg, but my issue is that a vast number of websites use Flash (mostly for ads), requiring me to "do something" on the notification bar for every website I visit (for the first time) - this seems excessive when all I want to do is say "never enable any plugin unless I click on a placeholder (usually a video or game, and one of the many accompanying ad panels".

I'll keep an eye on 942461.

Comment 45

[Gian-Carlo Pascutto [:gcp]]

A pref would be nice, but I think that in our current situation, with UX unfinished and Flash ubiquitous, this notification bar is actually doing more hurt than good. I filed 943382 to argue that case.

Comment 46

[Paul Silaghi, QA [:pauly]]

Verified fixed FF 28.0a1 2013-11-25 win 7

Comment 47

[Paul Silaghi, QA [:pauly]]

Attachment: hidden outdated flash.png

FWIW, the X button is barely seen on Windows for outdated plugins.

Comment 48

[Catalin Varga [QA][:VarCat]]

Verified as fixed with on Aurora 27.0a2 (build ID: 20131128004001) on: Win 7 64-bit, Mac OS X 10.8.5 and Ubuntu 12.04 32-bit.

Comment 49

[sjw]

Why does it affect the spotlight-module on youtube? And when I allow the plugin, the videoplayer is broken.

Comment 50

[Benjamin Smedberg]

sjw, I don't know what you're talking about, but commenting on this closed bug is probably not the best way. If you think there's a bug, could you please file it with specific steps to reproduce/results/etc?

Comment 51

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This feature doesn't work at all for me nowadays on http://connect.garmin.com/transfer/upload#. The plugin is hidden but even when I allow it in the add-on manager, or set to ask each time, its never getting started nor get I a notification. This has been regressed with Firefox 28 beta. I will investigate today and file a follow-up bug.