Closed Bug 1290912 Opened 8 years ago Closed 3 years ago

Integrate plugin notifications and icons into the new permissions UX concept

Categories

(Core Graveyard :: Plug-ins, defect, P3)

defect

Tracking

(firefox47 unaffected, firefox48 unaffected, firefox49 unaffected, firefox50 affected)

RESOLVED WONTFIX
Tracking Status
firefox47 --- unaffected
firefox48 --- unaffected
firefox49 --- unaffected
firefox50 --- affected

People

(Reporter: pauly, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fxprivacy])

[Affected versions]:
- 50.0a1 (2016-08-01)

[Affected platforms]:
- all

[Steps to reproduce]:
1. Have outdated flash installed (use http://benjamin.smedbergs.us/tests/ctptests/#single-outdated for testing)
2. Open http://wickedgoodgames.com/flash9/bongoboom.html - see the red crossed out icon
3. Click "Activate Adobe Flash"
4. Click "Allow now"

[Expected result]:
- Red icon shouldn't remain crossed out after unblocking the plugin

[Actual result]:
- Red icon remains crossed out after unblocking the plugin

[Regression range]:
- introduced once with the new design in bug 1285891
Whiteboard: [fxprivacy] [triage]
Flags: needinfo?(agrigas)
Whiteboard: [fxprivacy] [triage] → [fxprivacy]
We should probably solve Bug 901451 before this one.
Depends on: 901451
(In reply to Paul Silaghi, QA [:pauly] from comment #0)
> [Affected versions]:
> - 50.0a1 (2016-08-01)
> 
> [Affected platforms]:
> - all
> 
> [Steps to reproduce]:
> 1. Have outdated flash installed (use
> http://benjamin.smedbergs.us/tests/ctptests/#single-outdated for testing)
> 2. Open http://wickedgoodgames.com/flash9/bongoboom.html - see the red
> crossed out icon
> 3. Click "Activate Adobe Flash"
> 4. Click "Allow now"
> 
> [Expected result]:
> - Red icon shouldn't remain crossed out after unblocking the plugin
> 
> [Actual result]:
> - Red icon remains crossed out after unblocking the plugin
> 
> [Regression range]:
> - introduced once with the new design in bug 1285891

Agree the UI should be changed to show just the red plugin icon when a user unblocks flash. The icon with the line through it should only be used if the plugin is being blocked on the page.
Flags: needinfo?(agrigas)
(In reply to agrigas from comment #2)
> Agree the UI should be changed to show just the red plugin icon when a user
> unblocks flash. The icon with the line through it should only be used if the
> plugin is being blocked on the page.
Perhaps the same behavior should apply to the normal grey icon too?
I don't remember a separate "crossed out" version of the red icon. Could you provide a screenshot?

Perhaps this is just confusing iconography? This is a "do not enter" sign, and isn't supposed to look like something is crossed out.
Flags: needinfo?(paul.silaghi)
(In reply to Benjamin Smedberg [:bsmedberg] from comment #4)
> I don't remember a separate "crossed out" version of the red icon. Could you
> provide a screenshot?
> 
> Perhaps this is just confusing iconography? This is a "do not enter" sign,
> and isn't supposed to look like something is crossed out.

The new model we use in the url bar for permissions is to show the icon for the permission with a line through it if the permission is blocked/not allowed. We use this for gray icons and the plug in icon even though its red to be consistent. 

The red icon is here: https://files.slack.com/files-pri/T0K0M84G5-F1RMSKP7D/pasted_image_at_2016_07_14_10_54_am.png

Putting a line through the gray plugin brick wouldnt make sense unless it is being blocked. The gray icon with no line is used for the allowed state.
Aislinn, should the red icon ever be crossed out?  I've listed the scenarios below and my assumptions on what happens in each one.  Please correct me if I've got any of them wrong.


Scenarios:
1)User has non-vulnerable version of plugin click to play. 
* When they visit a website that would like to use that plugin, they see a grey icon in the url bar where they could allow or deny the plugin.

* If the user allows the action, the grey plugin remains in the url bar.

* If the user denys the action, the grey plugin appears crossed out in the url bar.  (Is there a deny button for flash in the new design?   I don't see one in Nightly yet.)

2)User has non-vulnerable version of plugin click to play. 
* When they visit a website that would like to use that plugin, they see a red icon in the url bar where they could allow or deny the plugin.

* If the user allows the action, the red plugin remains in the url bar.

* If the user denys the action, then what happens?
Does the red plugin remain in the url bar?  Does it remove itself from the url bar?  Does it get crossed out?  
If the user has explicitly denied a known vulnerable plugin, it would be nice for the red plugin icon to disappear.  It is scaring and alarming; if the user isn't going to use the plugin, they don't need to be reminded of it.  On the other hand, the reminder may push them to upgrade the plugin (if an upgrade is available, which it isn't always).  Also, if they discover they need the plugin later while browsing the page, the absence of the icon may make it hard for them to discover in the control center.

Thanks!
Flags: needinfo?(agrigas)
(In reply to Tanvi Vyas [:tanvi] from comment #6)
> Aislinn, should the red icon ever be crossed out?  I've listed the scenarios
> below and my assumptions on what happens in each one.  Please correct me if
> I've got any of them wrong.
> 
> 
> Scenarios:
> 1)User has non-vulnerable version of plugin click to play. 
> * When they visit a website that would like to use that plugin, they see a
> grey icon in the url bar where they could allow or deny the plugin.
> 
> * If the user allows the action, the grey plugin remains in the url bar.
> 
> * If the user denys the action, the grey plugin appears crossed out in the
> url bar.  (Is there a deny button for flash in the new design?   I don't see
> one in Nightly yet.)
> 
> 2)User has non-vulnerable version of plugin click to play. 
> * When they visit a website that would like to use that plugin, they see a
> red icon in the url bar where they could allow or deny the plugin.

Why would we show a red icon if its non-vulnerable? We should only use a red icon if we think the user needs to take an action like updating the plugin
> 
> * If the user allows the action, the red plugin remains in the url bar.
> 
> * If the user denys the action, then what happens?
> Does the red plugin remain in the url bar?  Does it remove itself from the
> url bar?  Does it get crossed out?  
If the user denys the action the red plugin icon with the line through it appears

> If the user has explicitly denied a known vulnerable plugin, it would be
> nice for the red plugin icon to disappear.  It is scaring and alarming; if
> the user isn't going to use the plugin, they don't need to be reminded of
> it.  On the other hand, the reminder may push them to upgrade the plugin (if
> an upgrade is available, which it isn't always).  Also, if they discover
> they need the plugin later while browsing the page, the absence of the icon
> may make it hard for them to discover in the control center.

I think for now it makes sense to leave the red icon with the line through it in this case until work is done to migrate plugin controls into the control center...
> 
> Thanks!
Flags: needinfo?(agrigas)
(In reply to agrigas from comment #7)
> (In reply to Tanvi Vyas [:tanvi] from comment #6)
> > 2)User has non-vulnerable version of plugin click to play. 
> > * When they visit a website that would like to use that plugin, they see a
> > red icon in the url bar where they could allow or deny the plugin.
> 
> Why would we show a red icon if its non-vulnerable? We should only use a red
> icon if we think the user needs to take an action like updating the plugin


Sorry, copy/paste error.  Scenario 2 should be the vulnerable plugin case.
Thanks for your answers Aislinn!  A couple more questions...

As part of the permissions overhaul scheduled to complete in 53, will plugin doorhangers have a deny action and look like the rest of the doorhangers?

(In reply to agrigas from comment #7)
> I think for now it makes sense to leave the red icon with the line through
> it in this case until work is done to migrate plugin controls into the
> control center...
> > 

Do you have a link to the design for what migrating plugin controls into the control center means?
Flags: needinfo?(agrigas)
(In reply to Tanvi Vyas [:tanvi] from comment #9)
> Thanks for your answers Aislinn!  A couple more questions...
> 
> As part of the permissions overhaul scheduled to complete in 53, will plugin
> doorhangers have a deny action and look like the rest of the doorhangers?
Yes the restyling will be done but the options will be the same as they are today i believe. I have to check with the team to see how much was in scope - I'm pretty sure its just restyling the buttons and layout slightly.
> 
> (In reply to agrigas from comment #7)
> > I think for now it makes sense to leave the red icon with the line through
> > it in this case until work is done to migrate plugin controls into the
> > control center...
> > > 
> 
> Do you have a link to the design for what migrating plugin controls into the
> control center means?
The ideal updated doorhanger would be like this but anchored off the brick like the other icon-anchored prompts:
https://www.dropbox.com/s/zzky6cfi69rcm99/Screenshot%202016-08-08%2013.15.15.png?dl=0

The controls then would live here:
https://www.dropbox.com/s/m2tqhlbps2llth6/Screenshot%202016-08-08%2013.15.37.png?dl=0

If a plugin is blocked by firefox for the user it would appear as the brick with line through it to the right of the "i". If the plugin is allowed by firefox or by user action, it wouldn't show and the "i" would just get badged with the dot. The control to stop allowed would be the X in the control center drop down menu.
Flags: needinfo?(agrigas)
(In reply to agrigas from comment #10)
> (In reply to Tanvi Vyas [:tanvi] from comment #9)
> > Thanks for your answers Aislinn!  A couple more questions...
> > 
> > As part of the permissions overhaul scheduled to complete in 53, will plugin
> > doorhangers have a deny action and look like the rest of the doorhangers?
> Yes the restyling will be done but the options will be the same as they are
> today i believe. I have to check with the team to see how much was in scope
> - I'm pretty sure its just restyling the buttons and layout slightly.

If the options are the same, then there is no deny button (just an allow and an allow and remember).  We would have to keep the X and dismissal behavior since there would be no other way to close the doorhanger without allowing the plugin (which the user may not want to do, especially if its red).
(In reply to Tanvi Vyas [:tanvi] from comment #11)
> (In reply to agrigas from comment #10)
> > (In reply to Tanvi Vyas [:tanvi] from comment #9)
> > > Thanks for your answers Aislinn!  A couple more questions...
> > > 
> > > As part of the permissions overhaul scheduled to complete in 53, will plugin
> > > doorhangers have a deny action and look like the rest of the doorhangers?
> > Yes the restyling will be done but the options will be the same as they are
> > today i believe. I have to check with the team to see how much was in scope
> > - I'm pretty sure its just restyling the buttons and layout slightly.
> 
> If the options are the same, then there is no deny button (just an allow and
> an allow and remember).  We would have to keep the X and dismissal behavior
> since there would be no other way to close the doorhanger without allowing
> the plugin (which the user may not want to do, especially if its red).

the version i see in nightly has a cancel... Let me ask the engineers what states they have. I've been using this reference:
http://benjamin.smedbergs.us/tests/ctptests/

I think we need to add a ticket to update the buttons to make sure its consistent. If we're adding the checkbox we shouldnt need the allow now and allow and remember options. So we should be able to add a 'Blocl' or 'Continue blocking' option to the one or two use cases that are missing it.
> The ideal updated doorhanger would be like this but anchored off the brick
> like the other icon-anchored prompts:
> https://www.dropbox.com/s/zzky6cfi69rcm99/Screenshot%202016-08-08%2013.15.15.
> png?dl=0

I'm concerned about this. The action that we want to promote to users is "allow and remember". This is a persistent permission that lasts for 90 days but renews automatically each time the site continues to use it. So if we're going to go with the checkbox, it should be checked by default.

But this is a significant change from the original design advice on this feature (from lco), where we explicitly chose not to show a "Don't Allow" button, because when this doorhanger is shown the user has already made an explicit click (we never auto-show the doorhanger). When this option is chosen, what happens? Does the plugin icon at least continue to stay visible so users can reverse their choice?
Flags: needinfo?(agrigas)
(In reply to Benjamin Smedberg [:bsmedberg] from comment #13)
> > The ideal updated doorhanger would be like this but anchored off the brick
> > like the other icon-anchored prompts:
> > https://www.dropbox.com/s/zzky6cfi69rcm99/Screenshot%202016-08-08%2013.15.15.
> > png?dl=0
> 
> I'm concerned about this. The action that we want to promote to users is
> "allow and remember". This is a persistent permission that lasts for 90 days
> but renews automatically each time the site continues to use it. So if we're
> going to go with the checkbox, it should be checked by default.
> 
We can do that.

> But this is a significant change from the original design advice on this
> feature (from lco), where we explicitly chose not to show a "Don't Allow"
> button, because when this doorhanger is shown the user has already made an
> explicit click (we never auto-show the doorhanger). When this option is
> chosen, what happens? Does the plugin icon at least continue to stay visible
> so users can reverse their choice?
Yes, the plugin icon will still be in the url bar with a strikethrough.
(In reply to Tanvi Vyas [:tanvi] from comment #14)
> (In reply to Benjamin Smedberg [:bsmedberg] from comment #13)
> > > The ideal updated doorhanger would be like this but anchored off the brick
> > > like the other icon-anchored prompts:
> > > https://www.dropbox.com/s/zzky6cfi69rcm99/Screenshot%202016-08-08%2013.15.15.
> > > png?dl=0
> > 
> > I'm concerned about this. The action that we want to promote to users is
> > "allow and remember". This is a persistent permission that lasts for 90 days
> > but renews automatically each time the site continues to use it. So if we're
> > going to go with the checkbox, it should be checked by default.
> > 
> We can do that.
> 
> > But this is a significant change from the original design advice on this
> > feature (from lco), where we explicitly chose not to show a "Don't Allow"
> > button, because when this doorhanger is shown the user has already made an
> > explicit click (we never auto-show the doorhanger). When this option is
> > chosen, what happens? Does the plugin icon at least continue to stay visible
> > so users can reverse their choice?
> Yes, the plugin icon will still be in the url bar with a strikethrough.

Maybe for the plugins case it makes sense to have the variant we've created for notifications since the temporary actions make less sense. I would prefer to change the button label and remove the checkbox then pre-checking something for the user:
https://www.dropbox.com/s/5v11zwtouh16coa/Screenshot%202016-08-09%2014.12.47.png?dl=0

Also, the doorhanger will never auto-open for plugins if it doesnt already. It will only open if we currently ask the user a questions (want to allow/block) and there answer is always reflected with a change to the icons in the url bar.
Flags: needinfo?(agrigas)
Well hrm. That screenshot gets rid of the "allow but just for now" option completely. Which is something that power users complained about.
ni?Bram so he's aware of this because he's working on plugin UI.
Flags: needinfo?(bram)
(In reply to Benjamin Smedberg [:bsmedberg] from comment #13)
> I'm concerned about this. The action that we want to promote to users is
> "allow and remember". This is a persistent permission that lasts for 90 days
> but renews automatically each time the site continues to use it. So if we're
> going to go with the checkbox, it should be checked by default.

Brendan's Brave browser gives users the choice of whitelisting Flash on a site for one day or one week:

"Flash disabled by default in @Brave. User enables per site, auto-disables after 1 week."

https://twitter.com/BrendanEich/status/763121374135136256

(In reply to Benjamin Smedberg [:bsmedberg] from comment #16)
> Well hrm. That screenshot gets rid of the "allow but just for now" option
> completely. Which is something that power users complained about.

We could simplify our UI by removing "Allow and Remember" (or the "Always remember my decision" checkbox) and only giving users a choice between "Allow Plugin" (for seven days, no auto-renewal?) and "Not Now". If someone allows Flash for a given site and they visit it again within a few days, they will probably want to keep using the site's Flash functionality.

For power users, we could offer a pref to control the "Allow Plugin" whitelist duration (in days or hours?), set it to 0 for only "allow once", or set to -1 for "allow forever".
Summarising the discussion found here and on bug:

* Default interface for other plugin blocking shows “Don’t Allow” and “Allow Plugin”, with an option to always remember decision
* We want default action for Flash to be "allow and remember"
* At the same time, we don’t want to show “Don’t Allow”, because the user have explicitly indicated that she wants to unblock

My proposal is to change a few things:

* Brick icon --> brick icon with a line through it
* “Would you like to allow [url] to run Adobe Flash?” --> “Adobe Flash is blocked on [url]”.
* [Don’t Allow] and [Allow Plugin] --> [Continue Blocking] and [Run Plugin]
* [Run Plugin] highlighted by default. When dialogue is shown, I can simply hit “Enter” to activate Flash
* If I hit “Escape”, [Continue Blocking] is selected
* The checkbox stays the same: [Always remember my decision] and ticked by default
* Whatever decision I’ve made, the brick icon disappears
* To change my decision, I either:
  * Click on the Control Center
  * Or, click again on the Flash element to show the slashed brick icon and get the permission dialogue

What I’m trying to do is to is shift away from an “ask for permission” model which assumes a neutral stance, to a “blocked by default” one which assumes that you don’t care about plugins (and that most websites should work without any plugin) unless you decide otherwise.

And I’m interested to test both approaches to see which one works better and will result in happier users (and instances of blocked plugins).

Question for Aislinn: have you thought of how to handle pixel Flash, where there’s no clickable area to trigger the permission dialogue? Can we use the existing dark grey bar on top of the page, or are we planning to retire this in favour of the standard modal dialogue?
Flags: needinfo?(bram) → needinfo?(agrigas)
(In reply to Bram Pitoyo [:bram] from comment #19)
> Summarising the discussion found here and on bug:
> 
> * Default interface for other plugin blocking shows “Don’t Allow” and “Allow
> Plugin”, with an option to always remember decision
> * We want default action for Flash to be "allow and remember"
> * At the same time, we don’t want to show “Don’t Allow”, because the user
> have explicitly indicated that she wants to unblock
> 
> My proposal is to change a few things:
> 
> * Brick icon --> brick icon with a line through it
> * “Would you like to allow [url] to run Adobe Flash?” --> “Adobe Flash is
> blocked on [url]”.
> * [Don’t Allow] and [Allow Plugin] --> [Continue Blocking] and [Run Plugin]
> * [Run Plugin] highlighted by default. When dialogue is shown, I can simply
> hit “Enter” to activate Flash
> * If I hit “Escape”, [Continue Blocking] is selected
> * The checkbox stays the same: [Always remember my decision] and ticked by
> default
> * Whatever decision I’ve made, the brick icon disappears
> * To change my decision, I either:
>   * Click on the Control Center
>   * Or, click again on the Flash element to show the slashed brick icon and
> get the permission dialogue
> 
> What I’m trying to do is to is shift away from an “ask for permission” model
> which assumes a neutral stance, to a “blocked by default” one which assumes
> that you don’t care about plugins (and that most websites should work
> without any plugin) unless you decide otherwise.
> 
> And I’m interested to test both approaches to see which one works better and
> will result in happier users (and instances of blocked plugins).
> 
> Question for Aislinn: have you thought of how to handle pixel Flash, where
> there’s no clickable area to trigger the permission dialogue? Can we use the
> existing dark grey bar on top of the page, or are we planning to retire this
> in favour of the standard modal dialogue?

So a few things - I think it would be helpful if we outline in a document - google doc? all of the possible plugin brick states so we're clear of the use cases that needed to be supported.

If a plugin is blocked by default, I don't think we should ask the user anything and let them clear out the blocking in the control center dropdown by clicking the X next to the row like this https://www.dropbox.com/s/2vvl741xawfl7zp/Screenshot%202016-08-11%2010.28.12.png?dl=0

If there are no clickable page elements to bring up plugin info - that shouldn't matter since the control center is where we want users to go to make changes about blocked or allowed plugins eventually versus a doorhanger off of the brick icon.

Lastly, I don't like the idea of us checking the checkbox for the user - its easily overlooked and takes away control from the user. If our pattern is that users always explicity check that when they want something to be permanent - checking it for them, breaks that pattern. If we really think that the main use case is always allow - I think we should modify the design completely for the plugin dialogue.
Flags: needinfo?(agrigas)
> If a plugin is blocked by default, I don't think we should ask the user
> anything and let them clear out the blocking in the control center dropdown
> by clicking the X next to the row like this
> https://www.dropbox.com/s/2vvl741xawfl7zp/Screenshot%202016-08-11%2010.28.12.
> png?dl=0
> 
> If there are no clickable page elements to bring up plugin info - that
> shouldn't matter since the control center is where we want users to go to
> make changes about blocked or allowed plugins eventually versus a doorhanger
> off of the brick icon.

I have user research from several years ago that users don't and won't notice anything in the location bar, and will simply think the website is broken. Do we think that has changed? The reason we have the notification bar is explicitly to call out to users that their page may be broken and how to fix it.

> Lastly, I don't like the idea of us checking the checkbox for the user - its
> easily overlooked and takes away control from the user.

Why aren't we talking about this in terms of what is the best default for most users. Typically, if a site needs to use Flash, it will keep needing to use Flash every time you visit. Therefore, making the permission persistent is the correct choice. We implemented the 90-day timeout so that as sites transition from Flash to non-Flash, the permission would eventually time out and reduce exposure to security risk.

The user research showed the users were definitely unhappy to be asked to make a decision every time they visited a site, and also that a similar checkbox was basically invisible to them: they didn't notice the persistent option and just blamed Firefox for asking them the same question over and over again.

Since the current UI was pretty highly tuned to user feedback and research, I really want us to approach this with evidence and data. Maybe that exists, but I haven't seen it in this bug.

The best doc I have currently to explain the various states is http://benjamin.smedbergs.us/tests/ctptests/ I'm happy to stick that into some other form if that would be helpful.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #21)
> > If a plugin is blocked by default, I don't think we should ask the user
> > anything and let them clear out the blocking in the control center dropdown
> > by clicking the X next to the row like this
> > https://www.dropbox.com/s/2vvl741xawfl7zp/Screenshot%202016-08-11%2010.28.12.
> > png?dl=0
> > 
> > If there are no clickable page elements to bring up plugin info - that
> > shouldn't matter since the control center is where we want users to go to
> > make changes about blocked or allowed plugins eventually versus a doorhanger
> > off of the brick icon.
> 
> I have user research from several years ago that users don't and won't
> notice anything in the location bar, and will simply think the website is
> broken. Do we think that has changed? The reason we have the notification
> bar is explicitly to call out to users that their page may be broken and how
> to fix it.

Maybe this warrants doing new testing? I've done research where users definitely commented on the red brick icon next to the lock even if they didn't update the plugin they new that it was there for a reason they're just to lazy to take an action...

Given we've reduced the number of icons shown in the url bar i think its more likely that the blocked brick icon with a line through it will be noticeable if the user is looking for a reason why something isn't working. We plan to do a usertesting.com study of the new notification design and could add a plugin state to further validate this in a few weeks.

If we really think we need to ask the user a question - we should replace the banner bar with our permissions dialogue instead of having a third way to ask permission.

I'm in agreement around not asking the user too many things which was why I proposed just removing the check box and having the button label reflect always remember. The open question is do we need to support block forever and block temporarily? Can the block forever be done more gobally in about permissions instead of in this temporal UI element?

I think there is a lot of simplification possible in the existing UI from the copy, number of choices and prompting behavior that is worthy of re-testing and exploration. There is very little consistency of button placement/options, website name placement,etc that overall make this a very hard to understand system. 

It would be great if you could outline in the google doc the main user cases in terms of intended interaction on part of the users and we should optimize for them meaning if we don't need to bother the user by having them confront options they arent aware of the trade offs of, we don't bother them.



> 
> > Lastly, I don't like the idea of us checking the checkbox for the user - its
> > easily overlooked and takes away control from the user.
> 
> Why aren't we talking about this in terms of what is the best default for
> most users. Typically, if a site needs to use Flash, it will keep needing to
> use Flash every time you visit. Therefore, making the permission persistent
> is the correct choice. We implemented the 90-day timeout so that as sites
> transition from Flash to non-Flash, the permission would eventually time out
> and reduce exposure to security risk.
> 
> The user research showed the users were definitely unhappy to be asked to
> make a decision every time they visited a site, and also that a similar
> checkbox was basically invisible to them: they didn't notice the persistent
> option and just blamed Firefox for asking them the same question over and
> over again.
> 
> Since the current UI was pretty highly tuned to user feedback and research,
> I really want us to approach this with evidence and data. Maybe that exists,
> but I haven't seen it in this bug.
> 
> The best doc I have currently to explain the various states is
> http://benjamin.smedbergs.us/tests/ctptests/ I'm happy to stick that into
> some other form if that would be helpful.
Removing needinfo as responded in comment 5.
Flags: needinfo?(paul.silaghi)
Whiteboard: [fxprivacy] → [fxprivacy] [triage]
[triage]: Johann are going to change the summary of this ticket in order to better capture the current conversation/decision we're needing to make.
Flags: needinfo?(jhofmann)
Whiteboard: [fxprivacy] [triage] → [fxprivacy]
Flags: needinfo?(jhofmann)
Summary: Red icon for outdated plugins shouldn't remain crossed out after unblocking the plugin → Integrate plugin notifications and icons into the new permissions UX concept
Priority: -- → P3
I'm going to create a corresponding design ticket and reference this so that there is a spec before we get to the dev bug.
Depends on: 1297990
This is the latest design document that I'm aware of: https://docs.google.com/spreadsheets/d/1H_4fZDLk5migyem5EHh_pNx26r8E_ytJF_hENLI7h-s/edit#gid=0
This should cover the control center and permission prompt pieces if I'm not mistaken.
Resolving as wont fix, plugin support deprecated in Firefox 85.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.