Include a context menu item to remove an add-on from Firefox when right clicking it on the toolbar

VERIFIED FIXED in Firefox 64

Status

enhancement
P3
normal
VERIFIED FIXED
2 years ago
6 months ago

People

(Reporter: jed-development, Assigned: Oriol)

Tracking

(Depends on 1 bug, {feature, parity-chrome})

57 Branch
mozilla64
Dependency tree / graph

Firefox Tracking Flags

(relnote-firefox 64+, firefox64 verified)

Details

Attachments

(4 attachments)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170920100426

Steps to reproduce:

Right click on an add-on's icon (URL bar, add-ons to the side of URL bar, and overflow menu add-ons).


Actual results:

The option 'Remove from Firefox' was not present.


Expected results:

The context menu item 'Remove from Firefox' or 'Remove from Nightly' in the case of Nightly could be included to improve overall usability. Chrome has such a feature and it's very useful.
Component: Untriaged → Toolbars and Customization
I think most of the work for this would need to happen on the webextensions side, to associate the browser action button with its add-on etc.
Component: Toolbars and Customization → WebExtensions: Frontend
Product: Firefox → Toolkit
Severity: normal → enhancement
Priority: -- → P3
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → All
Duplicate of this bug: 1454018
Depends on: 1457474
Product: Toolkit → WebExtensions
Oriol, now that bug 1457474 landed, any chance you'd like to pick this one up next?
Flags: needinfo?(oriol-bugzilla)
I don't know how to show a custom dialog and where to report bad addons according to https://mozilla.invisionapp.com/share/T7DZLW5CR
Flags: needinfo?(oriol-bugzilla)
(In reply to Oriol Brufau [:Oriol] from comment #4)
> I don't know how to show a custom dialog and where to report bad addons
> according to https://mozilla.invisionapp.com/share/T7DZLW5CR

For the custom dialog you can use Services.prompt.confirmEx. It won't have the custom icon from the design, but at least to me, that doesn't seem critical for a v1? Otherwise you'd have to write and show a custom XUL file yourself, which is substantially more work.

For the reporting, that's an interesting question, maybe :mconca knows.
Flags: needinfo?(mconca)
(In reply to :Gijs (he/him) from comment #5)
> (In reply to Oriol Brufau [:Oriol] from comment #4)
> > I don't know how to show a custom dialog and where to report bad addons
> > according to https://mozilla.invisionapp.com/share/T7DZLW5CR
> 
> For the custom dialog you can use Services.prompt.confirmEx. It won't have
> the custom icon from the design, but at least to me, that doesn't seem
> critical for a v1? Otherwise you'd have to write and show a custom XUL file
> yourself, which is substantially more work.

The icon for the modal is not a blocker. I'll be delighted to have the feature even if without the puzzle-piece.

> 
> For the reporting, that's an interesting question, maybe :mconca knows.


Regarding the 'Report abuse,' at the moment a user can report abusive extension exclusively from the single-page of the extension on AMO. 
https://screenshots.firefox.com/0lB93Et1gvotgBQv/addons.mozilla.org
https://screenshots.firefox.com/zF69SPJjXN8BdZQH/addons.mozilla.org

That's why the Invision dummy-click lands on the single-extension page. If it's too hard, I'm ok to drop this functionality for this first iteration.
Flags: needinfo?(mconca)
I may take a look when I have time, but without the 'Report abuse' functionality, which I don't really understand, e.g. what if the extension was not installed from AMO? And I think users would get confused if they want to report and are taken to the add-on page in AMO, it wouldn't be obvious that they are then supposed to find the "Report this add-on for abuse" button. IMO if in the dialog they say they want to report, then they should be taken directly to the form.
Sadly most accesskeys are already taken.
"O" is available but can be a strange choice.

Instead of
 - "remOve extension"
 - "manage Extension"
 - "Remove from toolbar"

it might be better to use
 - "rEmove extension"
 - "mAnage extension"
 - "Remove from toolbar"

or
 - "Remove extension"
 - "manage Extension"
 - "remove from Toolbar"

Thoughts?
Assignee: nobody → oriol-bugzilla
Status: NEW → ASSIGNED
(In reply to Oriol Brufau [:Oriol] from comment #8)
> Sadly most accesskeys are already taken.
> "O" is available but can be a strange choice.
> 
> Instead of
>  - "remOve extension"
>  - "manage Extension"
>  - "Remove from toolbar"
> 
> it might be better to use
>  - "rEmove extension"
>  - "mAnage extension"
>  - "Remove from toolbar"
> 
> or
>  - "Remove extension"
>  - "manage Extension"
>  - "remove from Toolbar"
> 
> Thoughts?

"RemoVe extension" is convenient and minimizes changes.

"remOve extension" is almost unavailable for one hand and efficiency.


I have a concern about the possibility of losing the data when remove an extension by mistake, hoping it has a good warning and avoiding misuse (such as accidentally pressing Space key or Enter key). For example, a countdown of 3 or 5 seconds, like the previous add-on install warning.
(In reply to YF (Yang) from comment #9)
> (In reply to Oriol Brufau [:Oriol] from comment #8)
> > Sadly most accesskeys are already taken.
> > "O" is available but can be a strange choice.
> > 
> > Instead of
> >  - "remOve extension"
> >  - "manage Extension"
> >  - "Remove from toolbar"
> > 
> > it might be better to use
> >  - "rEmove extension"
> >  - "mAnage extension"
> >  - "Remove from toolbar"
> > 
> > or
> >  - "Remove extension"
> >  - "manage Extension"
> >  - "remove from Toolbar"
> > 
> > Thoughts?
> 
> "RemoVe extension" is convenient and minimizes changes.
> 
> "remOve extension" is almost unavailable for one hand and efficiency.
> 
> 
> I have a concern about the possibility of losing the data when remove an
> extension by mistake, hoping it has a good warning and avoiding misuse (such
> as accidentally pressing Space key or Enter key). For example, a countdown
> of 3 or 5 seconds, like the previous add-on install warning.

In response to your concern about losing data and providing some form of warning, I have attached a quick mockup to this bug of what this dialogue box could look like.
(In reply to Jed from comment #11)
> In response to your concern about losing data and providing some form of
> warning, I have attached a quick mockup to this bug of what this dialogue
> box could look like.

I don't know how to show these dialogs, and I already had almost finished the patch using Services.prompt.confirmEx, so someone else can improve it in a follow-up bug.
(In reply to Oriol Brufau [:Oriol] from comment #13)
> (In reply to Jed from comment #11)
> > In response to your concern about losing data and providing some form of
> > warning, I have attached a quick mockup to this bug of what this dialogue
> > box could look like.
> 
> I don't know how to show these dialogs, and I already had almost finished
> the patch using Services.prompt.confirmEx, so someone else can improve it in
> a follow-up bug.

Jed, we already have a dialog as in this mock https://mozilla.invisionapp.com/share/T7DZLW5CR#/screens.
For this first iteration, we're not going to introduce the checkbox for the report abuse, but there is still a confermation dialog (see comment 7).
(In reply to emanuela [ux team] from comment #14)
> (In reply to Oriol Brufau [:Oriol] from comment #13)
> > (In reply to Jed from comment #11)
> > > In response to your concern about losing data and providing some form of
> > > warning, I have attached a quick mockup to this bug of what this dialogue
> > > box could look like.
> > 
> > I don't know how to show these dialogs, and I already had almost finished
> > the patch using Services.prompt.confirmEx, so someone else can improve it in
> > a follow-up bug.
> 
> Jed, we already have a dialog as in this mock
> https://mozilla.invisionapp.com/share/T7DZLW5CR#/screens.
> For this first iteration, we're not going to introduce the checkbox for the
> report abuse, but there is still a confermation dialog (see comment 7).

Maybe this requires a wording for the data of this add-on will be lost (and synced) and cannot be undone? Users may mistakenly believe that removing the button from Firefox. A revocable deletion is better.
(In reply to emanuela [ux team] from comment #14)
> (In reply to Oriol Brufau [:Oriol] from comment #13)
> > (In reply to Jed from comment #11)
> > > In response to your concern about losing data and providing some form of
> > > warning, I have attached a quick mockup to this bug of what this dialogue
> > > box could look like.
> > 
> > I don't know how to show these dialogs, and I already had almost finished
> > the patch using Services.prompt.confirmEx, so someone else can improve it in
> > a follow-up bug.
> 
> Jed, we already have a dialog as in this mock
> https://mozilla.invisionapp.com/share/T7DZLW5CR#/screens.
> For this first iteration, we're not going to introduce the checkbox for the
> report abuse, but there is still a confermation dialog (see comment 7).

Ahh, I wasn't aware this mockup existed.
Attachment #9001806 - Flags: review?(dao+bmo)
Comment on attachment 9001806 [details]
Bug 1401610 - Add "Remove Extension" context menu item to browserAction. r=dao

Dão Gottwald [::dao] has approved the revision.
Attachment #9001806 - Flags: review+
Attachment #9001806 - Flags: review?(dao+bmo)
Keywords: checkin-needed
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1ea4e6ffa2e6
Add "Remove Extension" context menu item to browserAction. r=dao
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/1ea4e6ffa2e6
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Depends on: 1489430
Posted image Bug1401610.gif
This issue is verified as fixed on Firefox 64.0a1(2018090232139) under Win 7 64-bit and Mac OS X 10.13.3.

"Remove Extension" - A dialog with “Remove” and “Cancel” buttons is present. After clicking on the “Remove” button, the extension is uninstalled from Firefox.

"Manage Extension" - redirects the user to the detailed page of the extension from about:addons.

“Remove from Toolbar" - removes the icon of the extension from the toolbar and it can be seen in the “Customize...” section.

If an extension has a menu item in the context menu, it will be displayed at the top of the list.

Please see the attached video.
Status: RESOLVED → VERIFIED
That should probably be added as a feature to  our release notes, Oriol would you mind requesting an addition to our release notes please? Thanks
https://wiki.mozilla.org/Release_Management/Release_Notes#How_to_nominate_a_bug_for_release_notes_addition.3F
Flags: needinfo?(oriol-bugzilla)
I don't see the "A form will pop up in the Bugzilla comments box" when I set relnote-firefox to "?"
Flags: needinfo?(oriol-bugzilla) → needinfo?(pascalc)
(In reply to Oriol Brufau [:Oriol] from comment #22)
> I don't see the "A form will pop up in the Bugzilla comments box" when I set
> relnote-firefox to "?"

After setting the flag to "?" you need to click on the "comment required" link and it will add the form into the comment. I'll update our documentation to make it clearer.
Flags: needinfo?(pascalc)
relnote-firefox: --- → ?
I don't
I don't get any "comment required" link anywhere :(
relnote-firefox: ? → ---
Release Note Request (optional, but appreciated)
[Why is this notable]: see comment #21
[Affects Firefox for Android]: No
[Suggested wording]: You can now use the context menu on toolbar buttons added by add-ons to remove the add-on.
[Links (documentation, blog post, etc)]: this bug? Not sure if Oriol or the add-ons team wants to blog about this change.
relnote-firefox: --- → ?
Thanks, note added to https://www.mozilla.org/en-US/firefox/64.0a1/releasenotes/. I am leaving the relnote-firefox? flag for the 64 release manager to decide if this should be mentioned in 64 Beta release notes.
Added to 64beta release notes:
You can now use the context menu on toolbar buttons added by add-ons to remove the add-on
I have been thinking that in https://mozilla.invisionapp.com/share/T7DZLW5CR it looks good because there are the "Learn More", "Extension Option 1" and "Extension Option 2" items at the top of the context menu.

But if the add-on doesn't add any custom items there, then the first one is "Remove Extension". I don't think such a predominant position is appropriate for an option that most probably won't be used regularly.

And I think it's easier to click the first item accidentally. Some people don't read confirmation dialogs, so this may end up causing data loss for them. It will be their fault, but moving the item so that it's not that easy to click by mistake would be beneficial.

So I think it would be better to have "Manage Extension" first and "Remove Extension" second.
Flags: needinfo?(emanuela)
Hey Oriol,

I don't see any issue in switching the two options as suggested.
Flags: needinfo?(emanuela)
Depends on: 1503600
You need to log in before you can comment on or make changes to this bug.