Update UI is too unobstrusive on OS X 10.8

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
6 years ago
a year ago

People

(Reporter: reuben, Unassigned)

Tracking

Trunk
All
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

6 years ago
With our new Notification Center based alerts system on OS X 10.8, update notifications are no longer shown when Firefox is in the foreground, and no longer fire alertclickcallback. This renders the alert system on Mountain Lion useless for the purpose of nsUpdateService. We should add a different type of UI (doorhanger maybe?) for those notifications on Mountain Lion.

I'd say this is a good-first-bug but I'm not sure what kind of UI can be used for this from Toolkit.

Comment 1

6 years ago
As I understand, doorhanger notifications are site-specific, or at least they seem to be. Thus, I'd not use a doorhanger notification for an update alert but rather the toolbar-like notification when sync fails (though, this type of notification also looks like a site info rather than a chrome info but finding a truly new notification type is another issue). 

However, further thinking about it, such a toolbar can be faked by websites thus causing a security issue … any other ideas?

Comment 2

6 years ago
With the new Australis theme, a doorhanger notification could be shown connected to the preferences (as opposed to the identitiy icon in the address bar) which will make it appear to be a chrome notification. Does this sound like a good idea?
Adding ux people. Also see bug 347585
I think it is also possible to generate a more 'sticky' notification on 10.8. One that will stay on the screen even if the App is open.

Like this one:

http://cdn-static.zdnet.com/i/story/50/06/369051/6369163.png

So it has a cancel button and a user defined button, which in our case could be 'Download'.

This is the same notification style that Apple's App Store app shows when new updates are available.

 S.
(Reporter)

Comment 5

6 years ago
(In reply to Stefan Arentz [:st3fan] from comment #4)

Right, the problem here is that Notification Center provides no way to know when an alert has been removed from the screen, so the current implementation sends the alertfinished callback as soon as the alert is shown. While we could create "actionable" style notifications, we'd send the click callback event *after* sending alertfinished.

Comment 6

6 years ago
Australis has an integrated notification center, see https://people.mozilla.com/~shorlander/files/appWide-notifications-i01/appWide-notifications-i01.html

Implementing this proposal should solve this problem/bug.
We no longer use alerts or the old ui. Closing old bugs as incomplete. If this is still an issue please file a new bug.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.