Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 676220 Native desktop notifications on Linux
Starred by 43 users Reported by mich...@lawton.nz, Dec 21 Back to list
Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Feature


Hotlists containing this issue:
Tracking
Hotlist-1


Sign in to add a comment
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Steps to reproduce the problem:
1. Trigger a desktop notification
(e.g. https://davidwalsh.name/demo/notifications-api.php)

What is the expected behavior?
The notification should use the desktop environment's notification system.

What went wrong?
The notification is displayed by Chromium's built in notification system.

Did this work before? No 

Chrome version: 55.0.2883.87  Channel: stable
OS Version: 
Flash Version: Shockwave Flash 24.0 r0

The freedesktop.org specification (https://developer.gnome.org/notification-spec/) is supported on many popular distributions on Linux. Notification servers implementing the specification are available for distributions and desktop environments which do not include support by default.

There are libraries (such as libnotify) available such for various languages which implement the specification.

A good overview of desktop notifications on Linux is https://wiki.archlinux.org/index.php/Desktop_notifications

There is a libnotify based extension for Firefox: https://addons.mozilla.org/en-US/firefox/addon/gnotifier/

At one time there were extensions available for Chromium but they were dependant on NPAPI
 
Components: -UI UI>Shell>Notifications
Labels: M-55 TE-NeedsTriageHelp
Cc: thomasanderson@chromium.org
Labels: -Pri-2 -M-55 Pri-3
Status: Untriaged
Confirming since someone on IRC asked about this exact thing.
I believe Gtk has a freedesktop-compliant notification API.  It wold probably make implementation relatively painless
I can confirm this on Ubuntu 16.04 LTS.
> I believe Gtk has a freedesktop-compliant notification API.  It wold probably make implementation relatively painless

GLib (Gio) has the GNotification API but it only is usable if you use GApplication which I presume Chromium never will. So you would either have to re-implement that yourself which is fairly trivial DBus usage or use a third party library like libnotify (which I would not recommend as it is a blocking API, though it could give a rough idea of usage).
Comment 6 Deleted
There's not much to the Dbus notifications API. I wrote a 100% async python module for use in Pithos so that we could rid ourselves of libnotify. (https://github.com/JasonLG1979/possibly-useful-scraps/blob/master/GioNotify.py) You don't need GApplication if you don't want to use it. All you need is Gio, Gobject, and Glib. You really don't even need that. I'm sure you could talk to Dbus without any tookit specific code if you wanted to. The notification spec is not desktop/toolkit specific. Although different desktops expose different features. For example, some allow for buttons in notifications and some don't and so on.
I'm not sure if it should be enabled by default since the native notification system works quite differently across the Linux desktop environments. On some desktops, like Unity, notifications aren't even clickable. Yes, native notifications look more consistent with the system UI, but it'll make behaviour and functionality of Chrome/Chromium notifications inconsistent across the DEs. For now, a simple chrome://flags switch would be a great thing to have, so the users can decide if they want it or not.
> On some desktops, like Unity, notifications aren't even clickable.

For some people, that's a plus. And if it's something someone couldn't live with, he wouldn't chose Unity in the first place.
> if it's something someone couldn't live with, he wouldn't chose Unity in the first place.

One might like Unity and used to use Chrome's/Chromium's clickable notifications. Interactiveness adds to the UX; it doesn't make it worse. Furthermore, on a browser, interactive notifications are extremely important since they're sent from the Internet which connects you to the outside world and clicking on it takes you to the appropriate place, so you can engage in real time, while, for example, when rendering is finished on your machine, there's not much of a point in having an interactive notification.
> One might like Unity and used to use Chrome's/Chromium's clickable notifications. Interactiveness adds to the UX; it doesn't make it worse. Furthermore, on a browser, interactive notifications are extremely important since they're sent from the Internet which connects you to the outside world and clicking on it takes you to the appropriate place, so you can engage in real time, while, for example, when rendering is finished on your machine, there's not much of a point in having an interactive notification.

In that case I would argue, that there's a point in clickable notifications and that they would benefit not only Chromium. Therefore they should be implemented upstream and not only in Chromium.
When it comes to clickable notifications there is an easy solution, check if the current DE supports them, if it does show native notifications, otherwise show chrome notifications.

With libnotify checking that is simple, just call: https://developer.gnome.org/libnotify/unstable/libnotify-notify.html#notify-get-server-caps , and check if it supports "actions".
Comment 13 Deleted
> In that case I would argue, that there's a point in clickable notifications and that they would benefit not only Chromium. Therefore they should be implemented upstream and not only in Chromium.

It won't be implemented in Unity 7, all the development is now focused on Unity 8 which is still unstable and, I believe, it's already implemented there. On KDE Plasma 5, the notification system is still in development, but I think, it's already mature enough to replace Chrome's notifications.

> When it comes to clickable notifications there is an easy solution, check if the current DE supports them, if it does show native notifications, otherwise show chrome notifications.

That seems to be a good option.
It should be possible for users who want libnotify regardless of clickability to be able to force it with some flag in chrome://flags/.
Everyone keeps conflating libnotify with the notification spec. libnotify is NOT the spec, it's merely a convenience lib(a crusty old blocking I/O lib at that) It would be best if everyone forgot it even existed. libnotify is not what you want to use. The notification spec is stupid simple. Just talk directly to DBus(hopefully in a purely asynchronous manner).  
> On some desktops, like Unity, notifications aren't even clickable.

I haven't read the Chromium notifications HIG(if it exists?) But notifications should be designed as not to assume that they were even seen let alone clickable. Notifications are a secondary interaction method not a primary method. Apps should be written so any interaction that notifications provided can also be done from the main UI. Providing functionality that can only be accessed though notifications is a big no, no.

Notifications should also be worded as to not assume intractability. For example "You have a new message" is preferred over "Click to check your new messages."     
Comment 18 Deleted
> Notifications are a secondary interaction method not a primary method. Apps should be written so any interaction that notifications provided can also be done from the main UI. Providing functionality that can only be accessed though notifications is a big no, no.

Removing functionality from notifications *is* the big no-no. If I receive a new email, a well-designed software should let me open it with a click of a button.

> It should be possible for users who want libnotify regardless of clickability to be able to force it with some flag in chrome://flags/.

Yes, providing a flag is the most important thing right now; in that case, everybody will be happy. But it should go both ways — users must be able to override both kinds of notifications. The question is, however, what should be the default behaviour. This one sounds nice:

> When it comes to clickable notifications there is an easy solution, check if the current DE supports them, if it does show native notifications, otherwise show chrome notifications.

So, although using native notifications should be a priority, having a fallback mode is a must.
> Removing functionality from notifications *is* the big no-no. If I receive a new email, a well-designed software should let me open it with a click of a button.

"well-designed software" would not rely on a popup notification for core functionality. A notification is just that a notification. Basically "Hey look at me something at least semi-important has happened." As I've said it should never be assumed to have even been seen let alone depended upon to drive interaction forward. Relying on transient/close-able notifications as a primary interaction method is a flawed design that can lead to dead ends in user interaction.   

Anyway, to my knowledge Unity7 is the only DE that doesn't support buttons in notifications. It's up for debate if Unity7 is in fact "well-designed software"...

> When it comes to clickable notifications there is an easy solution, check if the current DE supports them, if it does show native notifications, otherwise show chrome notifications.

Example outputs of org.freedesktop.Notifications.GetCapabilities and org.freedesktop.Notifications.GetServerInformation on Fedora 24:

Server information:
spec_version 1.2
vendor GNOME
name gnome-shell
version 3.20.3

Server Capabilities:
actions
body
body-markup
icon-static
persistence
sound

A couple things of note:
All images/icons are expected to be local files. So icon/images would have to be cached locally 1st. Remote image resources are a No, no.

body-markup is a bit of a lie. By markup they mean a very limited set.

actions = supports buttons.

persistence = All notifications are persistent, meaning they don't go away unless dismissed by the user. That can be overridden by passing the transient hint is desired.

I'd advise anyone interested to read the actual spec and not the libnotify docs.
 https://developer.gnome.org/notification-spec/  
> Anyway, to my knowledge Unity7 is the only DE that doesn't support buttons in notifications. It's up for debate if Unity7 is in fact "well-designed software"...

Not Unity 7; my point was regarding removing the features from Chrome/Chromium which makes interactive notifications possible on desktops that doesn't support it.
> Not Unity 7; my point was regarding removing the features from Chrome/Chromium which makes interactive notifications possible on desktops that doesn't support it.

Unity is the only DE that has it's own Notification server that doesn't support buttons to my knowledge. All the other more popular DE's (Gnome, Plasma(KDE), XFCE, Mate, Cinnamon, etc.) support buttons. But technically speaking you can install the notification system from one DE in another. And there is a possibility that a system may not even have a Notification server installed at all.

The 1st step would be to make sure the notification interface exists and then to check to see if the server supports actions. If so use native notifications if not use Chrome/Chromium notifications.   
Project Member Comment 23 by bugdroid1@chromium.org, Apr 5
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/421f86bb22686a086062ffde46fb746039dd2490

commit 421f86bb22686a086062ffde46fb746039dd2490
Author: thomasanderson <thomasanderson@google.com>
Date: Wed Apr 05 06:32:42 2017

Add initial support for native Linux desktop notifications

This CL adds a stub implementation of NotificationPlatformBridgeLinux,
which is responsible for communicating notification changes to the desktop
environment via D-Bus.  Once this class is fully implemented, it is
intended to be used by default when the host supports notifications.

BUG=676220
R=thestig@chromium.org,yoshiki@chromium.org

Review-Url: https://codereview.chromium.org/2794103002
Cr-Commit-Position: refs/heads/master@{#461990}

[modify] https://crrev.com/421f86bb22686a086062ffde46fb746039dd2490/chrome/browser/BUILD.gn
[modify] https://crrev.com/421f86bb22686a086062ffde46fb746039dd2490/chrome/browser/about_flags.cc
[modify] https://crrev.com/421f86bb22686a086062ffde46fb746039dd2490/chrome/browser/browser_process_impl.cc
[modify] https://crrev.com/421f86bb22686a086062ffde46fb746039dd2490/chrome/browser/notifications/notification_display_service_factory.cc
[modify] https://crrev.com/421f86bb22686a086062ffde46fb746039dd2490/chrome/browser/notifications/notification_platform_bridge.h
[add] https://crrev.com/421f86bb22686a086062ffde46fb746039dd2490/chrome/browser/notifications/notification_platform_bridge_linux.cc
[add] https://crrev.com/421f86bb22686a086062ffde46fb746039dd2490/chrome/browser/notifications/notification_platform_bridge_linux.h
[modify] https://crrev.com/421f86bb22686a086062ffde46fb746039dd2490/chrome/common/BUILD.gn
[modify] https://crrev.com/421f86bb22686a086062ffde46fb746039dd2490/chrome/common/chrome_features.cc
[modify] https://crrev.com/421f86bb22686a086062ffde46fb746039dd2490/chrome/common/chrome_features.h
[modify] https://crrev.com/421f86bb22686a086062ffde46fb746039dd2490/chrome/common/features.gni

Cc: -thomasanderson@chromium.org thestig@chromium.org peter@chromium.org
Labels: -Type-Bug Type-Feature
Owner: thomasanderson@chromium.org
Status: Started
X-reffing video for https://codereview.chromium.org/2805543005/
notification_demo.mp4
600 KB View Download
Project Member Comment 27 by bugdroid1@chromium.org, Apr 7
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/09fb058d6bfb0e74343a851f56e4032c44b56c19

commit 09fb058d6bfb0e74343a851f56e4032c44b56c19
Author: tonikitoo <tonikitoo@igalia.com>
Date: Fri Apr 07 17:00:22 2017

Guard native notification code under ENABLE_NATIVE_NOTIFICATIONS guards

about_flags.cc today opt in/out configurations manually, rather
than using the existing ENABLE_NATIVE_NOTIFICATIONS build flag.

This fixes the OZONE/Linux build.

BUG=676220
R=thomasanderson@google.com

Review-Url: https://codereview.chromium.org/2802243002
Cr-Commit-Position: refs/heads/master@{#462896}

[modify] https://crrev.com/09fb058d6bfb0e74343a851f56e4032c44b56c19/chrome/browser/about_flags.cc

Project Member Comment 28 by bugdroid1@chromium.org, Apr 7
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1e5d734b182b3bd7de2c36a88a26f05f857f59ec

commit 1e5d734b182b3bd7de2c36a88a26f05f857f59ec
Author: thomasanderson <thomasanderson@google.com>
Date: Fri Apr 07 23:24:08 2017

Linux native notifications:  Handle clicks and closes

This CL adds the initial wiring to GLib and
NativeNotificationDisplayService to get actions and closes working.

BUG=676220
R=thestig@chromium.org,peter@chromium.org

Review-Url: https://codereview.chromium.org/2805543005
Cr-Commit-Position: refs/heads/master@{#463045}

[modify] https://crrev.com/1e5d734b182b3bd7de2c36a88a26f05f857f59ec/chrome/browser/notifications/notification_platform_bridge_linux.cc
[modify] https://crrev.com/1e5d734b182b3bd7de2c36a88a26f05f857f59ec/chrome/browser/notifications/notification_platform_bridge_linux.h

I may be wrong but it looks like you're not sending an image or icon with the notifications? Generally speaking you want to send at least the app's icon.(chrome/chromium) you would send them as a string by name without the file extension.
c#29
That's because the impl is not done yet :)
When it is, I'll close this bug out as Fixed
For anyone wanting to try this out, you can in Chrome Dev (Unstable) by toggling 'Enable native notifications' in about://flags 
Works great for me. 
Elementary OS 64bit (Ubuntu 16.04 based) with Pantheon Desktop.

However it does not pass the picture (neither the picture included in the notification nor an application icon of some sort).
I tested it here: http://www.bennish.net/web-notifications.html
c#32  Images not yet implemented.  Work being done on this cl https://codereview.chromium.org/2806203003/
Project Member Comment 34 by bugdroid1@chromium.org, Apr 14
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d82f2908e3193915cdc573d54f962920714b847d

commit d82f2908e3193915cdc573d54f962920714b847d
Author: thomasanderson <thomasanderson@google.com>
Date: Fri Apr 14 01:41:46 2017

Linux native notifications: Support icons

This CL:
* Adds support for notification icons
* Adds an urgency hint
* Supports updating NotificationCommon::Type

BUG=676220

R=peter@chromium.org,thestig@chromium.org

Review-Url: https://codereview.chromium.org/2806203003
Cr-Commit-Position: refs/heads/master@{#464650}

[modify] https://crrev.com/d82f2908e3193915cdc573d54f962920714b847d/chrome/browser/notifications/notification_platform_bridge_linux.cc
[modify] https://crrev.com/d82f2908e3193915cdc573d54f962920714b847d/chrome/browser/notifications/notification_platform_bridge_linux.h

If possible, it should send along the "desktop-entry" hint so notification centers can group and/or filter based on the app that sent the notification (e.g. google-chrome.desktop)
>If possible, it should send along the "desktop-entry" hint so notification centers can group and/or filter based on the app that sent the notification (e.g. google-chrome.desktop)

The desktop-entry hint should NOT include .desktop.

"This specifies the name of the desktop filename representing the calling program. This should be the same as the prefix used for the application's .desktop file. An example would be "rhythmbox" from "rhythmbox.desktop". This can be used by the daemon to retrieve the correct icon for the application, for logging purposes, etc."

Other useful hints are category, action-icons, and transient.

category allows you to tell the notification server what type of notification you're sending it. There is a (rather limited) list of standard hints along with various non-standard vendor specific categories. For example x-gnome.music tells the notification server that the notification is a music notification in many notification servers.

Many notification servers support icons in the action buttons. You can check by looking for "action-icons" in the server capabilities. If you would like to show icons in the action buttons the icon name would be used as the action id.

In a few servers (GNOME for example) notifications are always persistent. Meaning they don't go away unless they are dismissed. You would check for that by looking for persistence in the server capabilities. You can override that with the transient hint if you like.  
Project Member Comment 37 by bugdroid1@chromium.org, Apr 18
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b6b0a4c62db4757a27a61f19921ed70df20a42be

commit b6b0a4c62db4757a27a61f19921ed70df20a42be
Author: thomasanderson <thomasanderson@google.com>
Date: Tue Apr 18 01:49:37 2017

Linux native notifications: Add support for custom notification buttons

BUG=676220
R=peter@chromium.org

Review-Url: https://codereview.chromium.org/2814973002
Cr-Commit-Position: refs/heads/master@{#465091}

[modify] https://crrev.com/b6b0a4c62db4757a27a61f19921ed70df20a42be/chrome/browser/notifications/notification_platform_bridge_linux.cc

Project Member Comment 38 by bugdroid1@chromium.org, Apr 18
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/196a305434d54e05c519f1f26e129d7cf2f863ba

commit 196a305434d54e05c519f1f26e129d7cf2f863ba
Author: thomasanderson <thomasanderson@google.com>
Date: Tue Apr 18 04:33:55 2017

Linux native notifications: Add desktop-entry hint

This CL adds a desktop-entry hint so that the notification server can
use the app's name and icon if it chooses to.

BUG=676220
R=thestig@chromium.org

Review-Url: https://codereview.chromium.org/2811183009
Cr-Commit-Position: refs/heads/master@{#465138}

[modify] https://crrev.com/196a305434d54e05c519f1f26e129d7cf2f863ba/chrome/browser/notifications/notification_platform_bridge_linux.cc

From the PyGobject docs:

cancellable.reset

Resets self to its uncancelled state.

If cancellable is currently in use by any cancellable operation then the behavior of this function is undefined.

Note that it is generally not a good idea to reuse an existing cancellable for more operations after it has been cancelled once, as this function might tempt you to do. The recommended practice is to drop the reference to a cancellable after cancelling it, and let it die with the outstanding async operations. You should create a fresh cancellable for further async operations.

Not sure if it applies to other languages or if it's Python specific but just a little food for thought. 
There's no real point in sending a cancellable along for the ride if you don't have to. (again in Python you can just send None) It doesn't close/cancel the notification. Once DBus gets it it's to late. cancellables are used to cancel pending async calls. Once the call is actually made you can't take it back. In this case to cancel a notification you'd have to be pretty darn quick, basically micro secs. 
c#39, c#40
The cancellable is going away soon as we're switching to a different dbus library.  It's original purpose was so that NotifyCompleteReceiver() didn't get called with an invalid pointer.
>as we're switching to a different dbus library

As in not Gio?

NotifyCompleteReceiver is the async callback for Notify correct? You should get either Null on an error or the Replace Id. In the case of an error handle the error and set the Replace Id back to 0. In my experience though I've never had Notify throw an error(as long as you feed it the proper data). If that were going to happen you would have ran into issues way before you got to that point. 


>It's original purpose was so that NotifyCompleteReceiver() didn't get called with an invalid pointer.

As I said unless you're a space ninja you couldn't possibly cancel that call even if you tried.
Project Member Comment 44 by bugdroid1@chromium.org, Apr 27 (3 days ago)
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/700d8c729c8d08f6aa42f15343f297ff5cfdf393

commit 700d8c729c8d08f6aa42f15343f297ff5cfdf393
Author: thomasanderson <thomasanderson@google.com>
Date: Thu Apr 27 03:16:05 2017

Refactor NotificationPlatformBridgeLinux

This CL:
* Removes the dependency on gdbus from NPBL and uses //src/dbus instead
* Handle notifications asynchronously on a dedicated task runner
* Modify NativeNotificationDisplayService to allow async initialization
  of the NotificationPlatformBridge (only on Linux)

BUG=676220
R=thestig@chromium.org

Review-Url: https://codereview.chromium.org/2821533003
Cr-Commit-Position: refs/heads/master@{#467563}

[modify] https://crrev.com/700d8c729c8d08f6aa42f15343f297ff5cfdf393/chrome/browser/BUILD.gn
[add] https://crrev.com/700d8c729c8d08f6aa42f15343f297ff5cfdf393/chrome/browser/notifications/DEPS
[modify] https://crrev.com/700d8c729c8d08f6aa42f15343f297ff5cfdf393/chrome/browser/notifications/native_notification_display_service.cc
[modify] https://crrev.com/700d8c729c8d08f6aa42f15343f297ff5cfdf393/chrome/browser/notifications/native_notification_display_service.h
[modify] https://crrev.com/700d8c729c8d08f6aa42f15343f297ff5cfdf393/chrome/browser/notifications/notification_platform_bridge.h
[modify] https://crrev.com/700d8c729c8d08f6aa42f15343f297ff5cfdf393/chrome/browser/notifications/notification_platform_bridge_android.cc
[modify] https://crrev.com/700d8c729c8d08f6aa42f15343f297ff5cfdf393/chrome/browser/notifications/notification_platform_bridge_android.h
[modify] https://crrev.com/700d8c729c8d08f6aa42f15343f297ff5cfdf393/chrome/browser/notifications/notification_platform_bridge_linux.cc
[modify] https://crrev.com/700d8c729c8d08f6aa42f15343f297ff5cfdf393/chrome/browser/notifications/notification_platform_bridge_linux.h
[modify] https://crrev.com/700d8c729c8d08f6aa42f15343f297ff5cfdf393/chrome/browser/notifications/notification_platform_bridge_mac.h
[modify] https://crrev.com/700d8c729c8d08f6aa42f15343f297ff5cfdf393/chrome/browser/notifications/notification_platform_bridge_mac.mm
[modify] https://crrev.com/700d8c729c8d08f6aa42f15343f297ff5cfdf393/chrome/browser/notifications/stub_notification_platform_bridge.cc
[modify] https://crrev.com/700d8c729c8d08f6aa42f15343f297ff5cfdf393/chrome/browser/notifications/stub_notification_platform_bridge.h
[modify] https://crrev.com/700d8c729c8d08f6aa42f15343f297ff5cfdf393/chrome/common/features.gni

Sign in to add a comment