Firefox notifications shouldn't be displayed over gnome panel

[Jan Frybort]

Binary package hint: firefox-3.0

Firefox 3 displays notifications (like when download is finished) over gnome panel. At that moment it makes switching to a different desktop impossible. The behaviour is illustrated by a screenshot.

[Hskupin (hskupin)]

As example Amarok already is using this way to show the track currently started playing:

http://upload.wikimedia.org/wikipedia/commons/e/eb/AmaroK_stable.png

[Hskupin (hskupin)]

As I read, there is a difference between per-user and system wide daemons. Firefox will be a client which connects to a per-user daemon, right? Updating summary.

[Gavin Sharp (gavin-sharp)]

Growl on OS X is exposed in Gecko using the nsIAlertsService API. Is "DBusMessage" something that could replace our current "custom" linux implementation of that interface?

[Hskupin (hskupin)]

So nsIAlertsService is only used for OS X at the moment? What API do we use to display alerts on Windows? Is there something?

But anyway, I'm not too familar with dbus. We only had a discussion on IRC yesterday about the topic of displaying notifications or alerts. Due to we are using dbus on trunk now I think it would be a good idea to have a wrapper component for DBusMessage on Linux. But we should ask someone with more knowledge.

[Gavin Sharp (gavin-sharp)]

No, nsIAlertsService is implemented on Mac, Windows, and Linux. For Mac it uses Growl, for Linux and Windows it uses a Gecko window that slides up. I was just wondering whether we could change the Linux implementation to use DbusMessage - though even if that would theoretically work requiring DbusMessage might not be feasible.

[Hskupin (hskupin)]

I searched the web and found some nice articles and specs about using dbus. I think the following URL could be the way of using the notification daemon to display any notification or alert on the desktop:

http://www.galago-project.org/specs/notification/0.9/index.html

How is it handled on OS X if Growl is not installed on the system? Do we have an alternated way? Is the normal AlertService used instead? I ask because it would be similar to this implementation.

[Fredrik Larsson (nossralf)]

Created attachment 295574
Potential look of Galago notifications.

This was generated using dbus-python and a Firefox icon to simulate how a Firefox notification could look if it was sent through dbus to Galago's libnotify/notification-daemon.

[Fredrik Larsson (nossralf)]

Currently, the main problem (probably) is that the DBus service in the tree only allows for a single client, and currently that's the NetworkManagerListener (to toggle offline mode automatically). So work needs to be done to extend the DBus service to handle multiple clients before it can conceivably be used for notifications. Perhaps that's a 2-hour job if you're a ninja like roc (the original implementer of the DBus service), I don't know.

(For Mozilla/DBus desktop integration in general, there is/was a Google SoC project called DBuzilla, but it seems abandoned and was separate from the main project to begin with. In the future it would be conceivable to expose interesting parts of Firefox through DBus: the download manager, Places and such. But that's another bug entirely.)

[Jakub 'Livio' Rusinek (liviopl-pl)]

We can use notify-send instead of direct DBus connection :> .

[Caillon (caillon)]

But DBus is better though as we can connect to ActionInvoked so we know when the user clicks on an action button. Which is what I'm doing and should have a patch this weekend.

[Jakub 'Livio' Rusinek (liviopl-pl)]

This bug should be dupe of bug #402934, but there were no action.

[Reed Loden (reed)]

*** Bug 402934 has been marked as a duplicate of this bug. ***

[Caillon (caillon)]

Hm, so there's a semi problem here, actually... Our alerts APIs expect to treat clicks on the actual notification as "action clicks", but the fd.o spec (and of course libnotify) treat that as a dismissal.

So, at this point we either need to change the way moz does notifications (which probably means changing strings and thus is not feasible right now), or get the spec changed and patch the notification library (which means this probably won't work on anything except the latest greatest distro)...

[Hskupin (hskupin)]

(In reply to comment #13)
> So, at this point we either need to change the way moz does notifications
> (which probably means changing strings and thus is not feasible right now), or

Axel, when is the final deadline for string changes?

[L10n-mozilla (l10n-mozilla)]

Deadline for string changes was last week.

Whether we break that for this depends on the amount of changes and the benefit of the change. The later this comes in, the smaller are its chances.

At this point, string changes are not the only argument against landing patches, too, but I have no idea what the regression risk is, what the current load of reviewers would be and all that.

[Reed Loden (reed)]

*** Bug 415417 has been marked as a duplicate of this bug. ***

[Hskupin (hskupin)]

There is also an ongoing discussion in the newsgroup:
http://groups.google.com/group/mozilla.dev.platforms.linux/browse_thread/thread/05f67b110fd6586d/988927e098b7b38c

[Jakub 'Livio' Rusinek (liviopl-pl)]

Bug 388743 is fixed, so the work can be continued, I think.

[Ispence (ispence)]

This bug was created after that bug was fixed, it is even referenced as being fixed in the first comment

[Caillon (caillon)]

It's like fitting a triangle into a square hole, here. In order to do this we need to change the way notification-daemon works or we need to change the way mozilla's notifications work. They just expect different things at this point. Which is frustrating because they are similar.

[Fredrik Larsson (nossralf)]

(In reply to comment #13)
> Hm, so there's a semi problem here, actually... Our alerts APIs expect to
> treat clicks on the actual notification as "action clicks", but the fd.o spec
> (and of course libnotify) treat that as a dismissal.

Is that necessarily a problem? If org.freedesktop.Notifications constitutes the "default behavior" for notifications on Linux, then one could argue that Firefox is currently equipped with the wrong user interface (vis-à-vis platform integration).

Of course, mapping the textClickable argument for showAlertNotification() to whether the text argument is an action or not may not always be pretty, but it's certainly possible.

[Jakub 'Livio' Rusinek (liviopl-pl)]

fd.o is "dismissed". See Gajim for example. Since notification provides "close" button, clicking doesn't dismiss the notification, but triggers action, and this is exactly what users expect.

fd.o isn't an organisation which always is right.

[Jan Frybort (jan.frybort)]

Binary package hint: firefox-3.0

Firefox 3 displays notifications (like when download is finished) over gnome panel. At that moment it makes switching to a different desktop impossible. The behaviour is illustrated by a screenshot.

[Roc-ocallahan (roc-ocallahan)]

(In reply to comment #13)
> Hm, so there's a semi problem here, actually... Our alerts APIs expect to
> treat clicks on the actual notification as "action clicks", but the fd.o spec
> (and of course libnotify) treat that as a dismissal.
>
> So, at this point we either need to change the way moz does notifications
> (which probably means changing strings and thus is not feasible right now), or
> get the spec changed and patch the notification library (which means this
> probably won't work on anything except the latest greatest distro)...

I'm not sure what the problem is, exactly. So clicking on libnotify's alert just dismisses it and there's no way to perform an "action click"?

If that's the problem, why is it considered a big problem? Because the notification strings imply you can click on the notification to make something happen? What's an example of that?

[Roc-ocallahan (roc-ocallahan)]

(In reply to comment #8)
> Currently, the main problem (probably) is that the DBus service in the tree
> only allows for a single client, and currently that's the
> NetworkManagerListener (to toggle offline mode automatically). So work needs to
> be done to extend the DBus service to handle multiple clients before it can
> conceivably be used for notifications.

It's easy enough to bang in another hardcoded DBus client there. It was designed to make that easy.

[Jeremy Visser (jeremy-visser)]

(In reply to comment #22)
> fd.o is "dismissed". See Gajim for example. Since notification provides "close"
> button, clicking doesn't dismiss the notification, but triggers action, and
> this is exactly what users expect.
>
> fd.o isn't an organisation which always is right.

Clicking _should_ dismiss the notification. It's the way other libnotify notifications behave, and we should aim to fit into the desktop environment as well as possible -- not simply try and emulate Growl or whatever.

Notice the cool new GTK+ integration features in Firefox 3.0? We should let that continue to libnotify.

The normal way for a user to initiate action from a libnotify dialog is to add a button to the balloon. See screenshot of a PackageKit notification for example:

http://www.packagekit.org/img/gpk-updates-warning.png

Clicking on the text in that example will dismiss the balloon, but clicking on the buttons will initiate action.

This is the preferred behaviour.

[Roc-ocallahan (roc-ocallahan)]

(In reply to comment #21)
> Of course, mapping the textClickable argument for showAlertNotification() to
> whether the text argument is an action or not may not always be pretty, but
> it's certainly possible.

Yeah.
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/alerts/public/nsIAlertsService.idl
Seems like if textIsClickable is true, we can just put the entire text in a button. Otherwise we leave the text as-is. A bit ugly, but comports with the current interface.

[Jakub 'Livio' Rusinek (liviopl-pl)]

Jeremy, test yourself what's comfortable, esp. in instant messenger - targeting into BIG notication or into LITTLE button?

And about "cool new GTK+ integration feature in Firefox 3.0" - I noticed nothing special...

[Jeremy Visser (jeremy-visser)]

(In reply to comment #27)
> Jeremy, test yourself what's comfortable, esp. in instant messenger - targeting
> into BIG notication or into LITTLE button?

Every desktop environment has its own interface culture and, simply, "the way things are done". They are done in that way for no apparent reason, other than that is the way it is "done" in that environment.

GNOME is no different. It has an established user interface with conventions and traditions. Do not dismiss these traditions simply on the grounds of personal preferences.

> And about "cool new GTK+ integration feature in Firefox 3.0" - I noticed
> nothing special...

Which brings me to this. Firefox 3.0 introduced much better support for GTK+ themes. Have you noticed that Firefox now has GTK+ stock icon support? Out-of-the-box, I have Tango icons that perfectly integrate with my GNOME theme.

XUL menus are now pixel-perfect with native GTK+ menus. Tabs are pixel-perfect, too. Even when using the latest Clearlooks theme, the ugly dotted selection rectangle is hidden, just as with native GTK+ apps. It now even uses the native GNOME print dialog when printing. You couldn't ask for more, could you? :)

This represented a great focus shift for Mozilla: that a familiar look and feel gains more new friends. I used to despise Firefox on Linux, because it didn't look, feel, and work like a GNOME application. Now, Epiphany has a serious run for its money.

The libnotify issue is like that. We should strive to fit in with the desktop.

If every GNOME developer designed their user interfaces according to his (or her) own personal tastes, GNOME would be the most lagubrious hodgepodge of soup ever created.

Global Mac menu with transparent toolbars on windows with pixel UI fonts with lolcats with landscape wallpapers (with GNOME logos pointlessly slapped on top) with glossy icons with inconsistent menu labelling with Mac-style dock launch with desktop icons to launch applications as well.

Is that the GNOME we know? No! It is beautiful and consistent. I may not agree with every decision they have made ("Preferences menu in Edit menu? What the heck?"), but what touches me is the special effort the developers have made to apply the unique and special GNOME culture all over.

[Jakub 'Livio' Rusinek (liviopl-pl)]

Thanks probably not good place for discussion...

> Every desktop environment has its own interface culture and, simply, "the way
> things are done". They are done in that way for no apparent reason, other than
> that is the way it is "done" in that environment.
>
> GNOME is no different. It has an established user interface with conventions
> and traditions. Do not dismiss these traditions simply on the grounds of
> personal preferences.

Notifications specs were done by fd.o people and they're know from being frequently not right. I don't know who introdoced "dismiss by default". It's app-specific, not to being specified anywhere...

For example "low battery" you probably want to dismiss, but notification from e-mail checker or instant messenger you want to do something when clicked.

> Which brings me to this. Firefox 3.0 introduced much better support for GTK+
> themes. Have you noticed that Firefox now has GTK+ stock icon support?
> Out-of-the-box, I have Tango icons that perfectly integrate with my GNOME
> theme.

Oh, forgot. That's so natural that it should this, so I forgot.

> XUL menus are now pixel-perfect with native GTK+ menus. Tabs are pixel-
> perfect, too. Even when using the latest Clearlooks theme, the ugly dotted
> selection rectangle is hidden, just as with native GTK+ apps. It now even
> uses the native GNOME print dialog when printing. You couldn't ask for more,
> could you? :)

Tabs are not so pixel perfect as you might think. Minor bug is present (like bug 412436 and more, reported by me, of course).

> This represented a great focus shift for Mozilla: that a familiar look and
> feel gains more new friends. I used to despise Firefox on Linux, because it
> didn't look, feel, and work like a GNOME application. Now, Epiphany has a
> serious run for its money.

Epiphany is doing some things better than Firefox - it starts faster, its history loads faster and when user wants to delete some history, it's done quick. However, Epiphany has no dropdown button in location bar and that's what I dislike in Epi. Another problem are extensions. No XPI support because of mixed UI (GTK+XUL) etc.

> The libnotify issue is like that. We should strive to fit in with the desktop.

I think that spec in fd.o should be a little modified to suite user needs. I'm not the only one who wants notification from IM/browser to do something, be sure ;) .

> If every GNOME developer designed their user interfaces according to his (or
> her) own personal tastes, GNOME would be the most lagubrious hodgepodge of
> soup ever created.

But, isn't it? Many things are done "because developer wanted to suite his needs", not "because users requested". Many things are ignored. Especially in big projects, where many bugs and requests are filed.

> Global Mac menu with transparent toolbars on windows with pixel UI fonts with
> lolcats with landscape wallpapers (with GNOME logos pointlessly slapped on
> top) with glossy icons with inconsistent menu labelling with Mac-style dock
> launch with desktop icons to launch applications as well.
>
> Is that the GNOME we know? No! It is beautiful and consistent. I may not agree
> with every decision they have mad...

[Blassey-bugs (blassey-bugs)]

maemo also uses DBus to display status updates, so this would be useful for mobile

[Alexander Sack (asac)]

not really sure if its better to hide the panel or some app window, but please search bugzilla.mozilla.org for this bug. if there is none, please file a new one and give us the bug id you got. Thanks!

[Ventnor-bugzilla (ventnor-bugzilla)]

Created attachment 353271
Use libnotify

At UDS Jaunty they discussed plans to remove the notification action callback functionality completely (as well as really sex up the notification popups). This makes it quite suitable for our own use considering the callbacks for the current alerts are redundant actions.

As for mobile, I saw libnotify installed on the Maemo system under /usr/lib (if you look at the terminal).

[Ventnor-bugzilla (ventnor-bugzilla)]

Comment on attachment 353271
Use libnotify

roc told me to file a new bug as this won't immediately give mobile support.

[Samuel Lidén Borell (samuellb)]

The current Mozilla-specific notification system is being replaced by the Free Desktop one (dbus notifcation), which should solve this problem.

https://bugzilla.mozilla.org/show_bug.cgi?id=404738

[Dao (dao)]

So is this a duplicate of bug 469880? If not, what's left to do?

[Martin Thoma (themoosemind)]

perhaps this addon for firefox could help you: https://addons.mozilla.org/en-US/firefox/addon/9622

[Mar-castelluccio (mar-castelluccio)]

Could someone explain what's the situation of notifications under Linux? Is there something else to work on?
We're going to use nsIAlertsService to give users feedback after a webapp successful installation (see bug 755934).

[Karlt (karlt)]

The libnotify implementation is a problem due to issues described in bug 750141.
It sometimes works, probably quite well for distro-compiled builds.

[Mar-castelluccio (mar-castelluccio)]

Bug 783765 landed, so we won't need this.