Open Bug 1494248 Opened 4 years ago Updated 4 years ago

"Requires new permissions" prompt design is counterproductive if user wants to investigate before saying OK

Categories

(Toolkit :: Add-ons Manager, defect, P3)

63 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: from_bugzilla3, Unassigned)

Details

(Whiteboard: [ux-decision-needed])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180920135444

Steps to reproduce:

1. See the icon on the hamburger menu
2. Click the transient menu entry to get access to a panel that actually says what permissions are being requested
3. Decide I want more information
4. Go into about:addons and click "More" for the extension



Actual results:

Once Firefox decides I intended to dismiss the prompt, there's no obvious way to get it back so I can OK the update.

Also, there's apparently no way to get from an about:addons page to an AMO page (to see if the author explains their choice of requested permissions in the release notes) unless the author specified the AMO page as the addon's home page.

(It took me far too long to figure out that "Reload in address bar" gained a need for "Access your data for all websites" in order to differentiate between Click, Shift+Click, and Ctrl+Click for the new "reload in new tab" and "reload, bypassing cache" features.)


Expected results:

Either the "Requires new permissions" panel should refuse to dismiss, like the "Add [extension name]?" panel or it should leave an icon in the address bar that can be clicked to recall it, like the prompt for saving something into the password manager.

Also, given that everything has to be signed by Mozilla now, about:addons pages should always include a link to pull up the corresponding AMO page.

(It might also be a good idea to include a link to the corresponding release notes entry in the "Requires new permissions" panel.)
Component: Untriaged → Add-ons Manager
Product: Firefox → Toolkit
(In reply to Stephan Sokolow from comment #0)
> Also, given that everything has to be signed by Mozilla now, about:addons
> pages should always include a link to pull up the corresponding AMO page.

Just because an extension is signed by AMO does not mean it has a public page.  This is the difference between listed and unlisted extensions.

In any case, forwarding your request to UX.  Emanuela, any thoughts on comment 0?
Flags: needinfo?(emanuela)
Whiteboard: [ux-decision-needed]
(In reply to Andrew Swan [:aswan] from comment #1)
> Just because an extension is signed by AMO does not mean it has a public
> page.  This is the difference between listed and unlisted extensions.

For the record, I just realized that there *is* an implementation of what I want already... the "X reviews" link in the Rating row of the metadata block.

Requires a bit more of an intuitive leap than would be ideal, but at least an "AMO page" link *is* present.
We're not planning to change how permissions work right now.
Flags: needinfo?(emanuela)
I think there are a few issues to pull out of this for consideration (or inclusion in whatever the appropriate work might be):

1) can't select the text of the permissions in the doorhanger
2) there's no link from there to a page explaining the permissions
3) there's no link to the extension's AMO page from the detail view in about:addons
While that's true, I'd consider the primary problem to be:

4) If the user attempts to research the change in permissions, the permissions prompt dismisses itself and there is no obvious way to then regain access to the button to grant the new permissions. (aside from making a note on what to choose when it eventually decides to return on its own at some later date for reasons unclear.)

That encourages anyone who actually reads permissions prompts (rather than blindly accepting anything) to stay on old versions of extensions by giving them a choice between "OK the permission right now, without researching it" or "Research the reason for the permission, but then be unable to OK it".
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.