Closed Bug 374538 Opened 17 years ago Closed 2 years ago

Modify nsIAlertsService API

Categories

(Toolkit Graveyard :: Notifications and Alerts, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: sdwilsh, Unassigned)

References

()

Details

While working with the mac implementation for nsIAlertsService, I've come up with some thoughts on the current API, and how we can improve it.  This interface is unfrozen, so it can be changed.

1) Remove the textClickable
The only way this is useful, is if you pass an observer in, and an observer is almost useless unless you set this to true (it will only dispatch a notification when the message is complete).  On windows and linux, the text appears as a hyperlink when the text is clickable, but we can just listen for a click on the whole notification box (which to me seems more sensible, but that's my opinion)

2) Add the ability to do stick notifications
They stay there until the users dismisses them.  I believe mconnor might have mentioned this, but I'm not so sure.  This can be useful, and it can be abused.

(1) would require a modification of the current function, while (2) could be done with a new function, showStickAlertNotification.
Blocks: 391598
any work here happening for FF3 considering the dependent bugs 334767 & 391598 ? re-targeting ?
I do not believe anyone is working on this.  If someone is interested in picking it up, I can provide some pointers on what needs to be done.
Assignee: nobody → matthew
No longer blocks: 391598
If these type notifications could be optionally made sticky such as in using them to alert users to new or updated add-ons having been installed, they could then be used to fix Bug 447570.
I'm somewhat concerned about stacked alerts (e.g. notify of new add-ons installed, notify of app update, etc.) with the sticky approach. Something along 347585 comment #10 might remedy this. Perhaps acknowledging the sticky alert would either bring up a list of previous alerts that were set with sticky?
(In reply to comment #4)
> I'm somewhat concerned about stacked alerts (e.g. notify of new add-ons
> installed, notify of app update, etc.) with the sticky approach. Something
> along 347585 comment #10 might remedy this. Perhaps acknowledging the sticky
> alert would either bring up a list of previous alerts that were set with
> sticky?
> 
Bug 347585 (add link to bug)
(In reply to comment #5)
> See also bug 324570
Hmmm... with bug 324570 people *might* be more likely get into the habit of just acknowledging alerts . I believe a single UI for seeing multiple alert history at the same time would be better and more user friendly especially for the case of system alerts such as add-ons installed and app update.
(In reply to comment #7)
> (In reply to comment #5)
> > See also bug 324570
> Hmmm... with bug 324570 people *might* be more likely get into the habit of
> just acknowledging alerts . I believe a single UI for seeing multiple alert
> history at the same time would be better and more user friendly especially for
> the case of system alerts such as add-ons installed and app update.
> 

I like the idea of being able to see the alert history. It might be worthwhile to cobble up an extension to test the idea and get user feedback before put it into the Toolkit.
Bulk move to Toolkit::Notifications and Alerts

Filter on notifications-and-alerts-component.
Component: XUL Widgets → Notifications and Alerts

The bug assignee didn't login in Bugzilla in the last 7 months.
:tspurway, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: matthew.gertner → nobody
Flags: needinfo?(tspurway)
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(tspurway)
Resolution: --- → WONTFIX
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.