791615 - API for social notification icons needs way to remove icons

Status: RESOLVED DUPLICATE of bug 935640

(Firefox Graveyard :: SocialAPI, defect)

Description

[Mark Hammond [:markh] [:mhammond]]

Once a provider specifies an "ambient notification" icon, there is no facility the provider can use to remove the notification - once specified it will be there until the browser is restarted.

In effect, this means the notifications supplied by the provider must be fixed - while new ones can be added, the inability to remove old ones makes the ability to dynamically add new ones difficult to leverage.

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

I think we should remove the ability to dynamically add/remove icons. I think the manifest should specify all the toolbar icons. The current method of dynamically adjusting toolbar state makes the behavior of the browser kind of clumsy.

Adjusting notification counts for icons can remain dynamic, but IMO adding/removing toolbar buttons seems unneeded.

Comment 2

[Mark Hammond [:markh] [:mhammond]]

(In reply to Jared Wein [:jaws] from comment #1)
> I think we should remove the ability to dynamically add/remove icons.

Yeah - so I guess we can use this bug to track that.  I'm not 100% convinced adding them to the manifest is worthwhile, but the current api is certainly under-specified.

We almost need a category for "api" bugs - it's not time-sensitive so "minor"

Comment 5

[Mark Hammond [:markh] [:mhammond]]

Sorry for the bug-spam.  This is a first cut at bugs that need (or potentially need) a change to the social api to be implemented appropriately.

Comment 6

[edA-qa mort-ora-y]

I don't think they should be part of the manifest. This would then prevent the provider from allowing the user to configure whether the icons are used or not. Our provider will use an icon, and I can forsee that many of our users would not want to see the icon, thus I'd like to provide an option to turn it off.

Comment 7

[Mark Hammond [:markh] [:mhammond]]

(In reply to edA-qa mort-ora-y from comment #6)
> I don't think they should be part of the manifest...

I'm still forming an opinion here, but the other side of the coin is that Firefox may prefer to keep some control over this part of the UI, given it is in the Firefox chrome.  Eg, a consistent set of icons would allow FF to treat an icon like any other part of the toolbar (full "customize" support, for example), or implement other policies.  If the provider was able to show/hide icons, or create new ones that appear unrelated to ones seen before, we'd lose some control over the UX.

Against that though is that we eventually need to support provider-supplied manifests and automatically updating them periodically, so having them in the manifest doesn't really make them particularly "stable"...

Comment 8

[edA-qa mort-ora-y]

If the user could remove the button via normal FireFox customization, and add it back later, that'd be great! Then the manifest would simply list the available buttons, and perhaps which are shown by default.  The social API would then need someway to determine which ones are visible (to avoid wasted processing updating numbers on invisible buttons).

Comment 9

[Shane Caraveo (:mixedpuppy)]

ambient panels/buttons are gone as of bug 935640