Closed Bug 803344 Opened 9 years ago Closed 9 years ago

poor discoverability of the enable/disable menu item for Social API


(Firefox Graveyard :: SocialAPI, defect)

Not set


(firefox17+ verified, firefox18+ verified, firefox19 verified)

Firefox 19
Tracking Status
firefox17 + verified
firefox18 + verified
firefox19 --- verified


(Reporter: Gavin, Assigned: jaws)



(Keywords: late-l10n, Whiteboard: [fx17])


(1 file, 2 obsolete files)

Currently, the only user-exposed way to disable the social API once it has been enabled is by using the menu item that appears in the Tools menu (and app menu on Windows). Discovering that menu item exists is not easy, because it's not clearly associated with the feature after activation (which happens in content).

There is a "Show sidebar" menu item in the toolbar button dropdown, and many users are confusing that with a global enable/disable. We used to have a "Remove from Firefox" menu item, but that was removed in bug 783928 because we were concerned about the opposite problem: people removing the feature accidentally and not knowing how to get it back.

As a compromise, we could re-add the "Remove from Firefox" menu item, but make it a two-step process that requires confirmation. Boriss has some mockups for how this should work.
This will probably require a string, and
Keywords: late-l10n
I was talking with Felipe yesterday and had an idea that will require no-l10n changes and also solves one of the usability problems with this potential menuitem.

Basically, social providers are already the place where users activate, and so they should have the ability to deactivate as well.

On the social providers site, they should be able to dispatch a custom event named "DeactivateSocialFeature" which would turn off the feature.

This would allow social providers an easy toggle-switch as well as let them do the localization for this. There's bonus points too since the user can go back to where they enabled it to disable it, which can provide a nice feedback loop for the social provider as well.
I think that's a good idea, but I don't think it solves the whole problem (we'd still be reliant on the providers, not having a clear way *in Firefox* to disable a Firefox feature is still confusing). We'd probably also want a notification for when the disabling happens, for the same reasons we have one on activation, and that would require a string anyways. We should definitely investigate in a new bug, but I don't think it necessarily needs to block 17.

The new string requirement here is not a game killer. An un-localized string is not ideal, but it's also not disastrous, and I think the benefits outweigh the costs. So let's do this, ASAP :)
This solution doesn't require any late string changes, and will allow users to deactivate the featureset at the same place where they activated it.

Gavin or Felipe, can either of you review this? I flagged both of you just to increase chances of response time.
Assignee: nobody → jaws
Attachment #673746 - Flags: review?(
Attachment #673746 - Flags: review?(felipc)
I didn't see comment #3 before attaching the patch... I'll work on a string approach too. With that being said, I do think what we have today isn't *horrible*, documentation can help users.
Comment on attachment 673746 [details] [diff] [review]
Patch to allow content to disable social api

I don't think we want to do this without a notification, but I might be convinced otherwise. More importantly, I don't think this is sufficient to address this problem in 17, per my earlier comment.
Attachment #673746 - Flags: review?( → review-
Depends on: 783928
This patch adds three strings (one for the menuitem and two for the confirmation dialog).
Attachment #673746 - Attachment is obsolete: true
Attachment #673746 - Flags: review?(felipc)
Attachment #673749 - Flags: review?(
Attachment #673749 - Flags: review?(felipc)
The mockups from boriss that I remember had a confirmation right in the menu, rather than a normal prompt. Probably more annoying to implement (and a bit of an unusual interaction for a menu), but it seemed nicer than a modal confirmation prompt, and potentially requires fewer strings.
Duplicate of this bug: 804218
Duplicate of this bug: 804260
This is the old mockup that Boriss made which shows the removal from the menu,
Duplicate of this bug: 804624
This patch implements inline confirmation.

See for a screencast demo.
Attachment #673749 - Attachment is obsolete: true
Attachment #673749 - Flags: review?(
Attachment #673749 - Flags: review?(felipc)
Attachment #674405 - Flags: review?(
Attachment #674405 - Flags: review?(felipc)
Duplicate of this bug: 804235
This is a screencast that shows the buttons all the time but with them disabled until the user clicks on the menuitem to remove the feature:

This is a screencast that sets the visibility of the buttons to hidden until the menuitem is clicked on:

This is a screencast of the confirmation dialog interaction:

See comment #13 for the fourth option.
Asa/Boriss: we need to make a call here ASAP. Can you comment on Jared's proposed solutions and decide which you think is best, or suggest an alternative?

My opinion: the prompt built-in to the menu item is unusual and neither of the options really look very good. Additionally, this is a entirely novel kind of interaction, so getting it right seems tricky. So for Firefox 17, I think we should go with the modal dialog confirmation prompt - it's not ideal, but it's simple to implement, and a well known interaction model.

One suggested addition: add a short bit of text to the prompt that explains how to re-activate. Not sure how to best mention this concisely and generically, though.
Another option, that doesn't do major resizing of the menupopup but keeps the buttons in context,
We discussed this a bit on IRC.

I'd suggest proceeding with a standard modal prompt, for the reasons gavin already noted. Most people will see this only 0 or 1 times, so IMO simple+familiar wins out over novel UI. And, of course, we can always change it later.

I think the 3 of us that chimed in all agreed that horizontally resizing the prompt is too jarring. And so if an alternative to the modal prompt is needed, something like comment 17 is the next-best option of those proposed so far.
Duplicate of this bug: 805445
Comment on attachment 674405 [details] [diff] [review]
Patch with inline confirmation (3 strings)

OK, let's do the prompt. Is attachment 673749 [details] [diff] [review] what I should review?
Attachment #674405 - Flags: review?(
Attachment #674405 - Flags: review?(felipc)
Comment on attachment 673749 [details] [diff] [review]
Patch to add menuitem and confirmation dialog

Yeah, this is the right patch for the confirmation dialog.
Attachment #673749 - Flags: review?(
Attachment #674405 - Attachment is obsolete: true
Attachment #673749 - Attachment is obsolete: false
Whiteboard: [fx17]
Attachment #673749 - Flags: review?( → review+
Comment on attachment 673749 [details] [diff] [review]
Patch to add menuitem and confirmation dialog

[Triage Comment]
Let's get this uplifted for Firefox 17/18. We'll need to coordinate with localizers about the late string change.
Attachment #673749 - Flags: approval-mozilla-beta+
Attachment #673749 - Flags: approval-mozilla-aurora+
Closed: 9 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Once XULNotifications / Australis lands, I'd propose to do the same as during installation: Just remove it, and display a notification informing the user that he removed X with the option to undo the change (other option: "OK").
Is there any QA testing needed here?
Probably worth verifying that the social toolbar item has a "remove from firefox" (sp?) option, and when selected it displays a confirmation prompt that (a) makes sense and (b) works as expected.
Thanks Mark. Verified fixed. Nominating this for a QA l10n test.
Flags: in-moztrap?
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.