If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Improve UX for out-of-date plugins

NEW
Unassigned

Status

()

Firefox
General
7 years ago
a month ago

People

(Reporter: ladamski, Unassigned)

Tracking

({sec-want})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:want P1])

Attachments

(3 attachments)

(Reporter)

Description

7 years ago
For installed plugins that are significantly out of date and putting the user at risk, we should consider some in-content UI to guide the user strongly towards updating.  

Potential options include:
a) click to play
b) disabled by default with notification - per page
c) enabled by default with notification - per page
d) site whitelists, managed by user and/or us
e) likely many other options not mentioned here... don't want to constrain discussion here

Another side benefit (depending on the approach) could be that out-of-date plugin content isn't instantiated by default, reducing the risk to users who don't update.

For maximum effectiveness we'd want to improve plugin updating as well.  The UI should at least try to communicate to the user why the plugin is being disabled/limited and provide next steps to update.
(Reporter)

Updated

7 years ago
See Also: → bug 597128
This doesn't seem like a bug that needs to be marked security-sensitive - any objections to opening it up?
Created attachment 476869 [details]
Mockup: notification states of add-ons in the add-ons manager for Firefox 4.0

Currently, because plugins are the only type of add-on that are not automatically updated by default, a panel notification displays on startup which notes that a plug-in is out of date.  This links to the specific website of that plugin.  A similar notification displays when the user hits content that doesn't display because of that plugin.

Notifications for add-ons within the add-ons manager display like the attached mockup, with a color and striped background and a text notification.  We could use the yellow notification for an out-of-date plugin with a link somewhere inline to where the user can update.

Comment 4

7 years ago
Is there a particular reason we need to do this on startup, instead of the first time we try to use the bad plugin?
(In reply to comment #4)
> Is there a particular reason we need to do this on startup, instead of the
> first time we try to use the bad plugin?

No, we can wait for first use.
To clarify for the discussion. The outdated plugin notification that we currently support (and have since Firefox 3.6) is this:

The blocklist can include information about outdated plugins in it. After it has updated and shows a newly outdated plugin:

On the next restart of Firefox we load the plugin check page.
When accessing a page that uses the plugin we show a notification bar that links the user to plugin check.
In the add-ons manager we show a notification about the plugin saying it is outdated and linking to the plugin check page.
Created attachment 476874 [details]
Current add-ons manager notification
Created attachment 476875 [details]
Current in-page notification

Updated

7 years ago
Group: core-security

Updated

7 years ago
Whiteboard: [sg:want P1]
>Currently, because plugins are the only type of add-on that are not
>automatically updated by default, a panel notification displays on startup
>which notes that a plug-in is out of date.

by "a panel notification displays on startup", do you mean a site based notification on start up?
Keywords: sec-want
You need to log in before you can comment on or make changes to this bug.