Closed Bug 785904 Opened 12 years ago Closed 7 years ago

Update UI is too unobstrusive on OS X 10.8

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: reuben, Unassigned)

References

(
URL
)

Details

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.
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?
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.
(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.
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
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.