Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 71 users
Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Feature


Show other hotlists

Hotlists containing this issue:
Hotlist-1
ZapList


Sign in to add a comment
Native desktop notifications on Linux
Reported by mich...@lawton.nz, Dec 21 2016 Back to list
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
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

Project Member Comment 46 by bugdroid1@chromium.org, May 3
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cbe7b7a3a4f5839a11461031904555c4c9eac92a

commit cbe7b7a3a4f5839a11461031904555c4c9eac92a
Author: thomasanderson <thomasanderson@google.com>
Date: Wed May 03 04:26:32 2017

Linux native notifications: Implement GetDisplayedNotifications

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

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

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

Project Member Comment 48 by bugdroid1@chromium.org, May 4
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cb0550026886b2cdcd7bb9c975910dcb85056b4c

commit cb0550026886b2cdcd7bb9c975910dcb85056b4c
Author: thomasanderson <thomasanderson@google.com>
Date: Thu May 04 19:52:55 2017

Linux native notifications: Add server capabilities metrics

This CL adds the following metrics:

* If the system has a dbus object at /org/Freedesktop/Notifications
  with interface org.Freedesktop.Notifications
* Server capabilities as returned by GetCapabilities
  * Capabilities are stored in |capabilities_|.  It is not used now,
    but will be in the future.
* Whether native notifications are actually used

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

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

[modify] https://crrev.com/cb0550026886b2cdcd7bb9c975910dcb85056b4c/chrome/browser/notifications/native_notification_display_service.cc
[modify] https://crrev.com/cb0550026886b2cdcd7bb9c975910dcb85056b4c/chrome/browser/notifications/notification_platform_bridge_linux.cc
[modify] https://crrev.com/cb0550026886b2cdcd7bb9c975910dcb85056b4c/chrome/browser/notifications/notification_platform_bridge_linux_unittest.cc
[modify] https://crrev.com/cb0550026886b2cdcd7bb9c975910dcb85056b4c/tools/metrics/histograms/enums.xml
[modify] https://crrev.com/cb0550026886b2cdcd7bb9c975910dcb85056b4c/tools/metrics/histograms/histograms.xml

Project Member Comment 50 by bugdroid1@chromium.org, May 9
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/75583a655243a5dc047509e3524822ab8ae06706

commit 75583a655243a5dc047509e3524822ab8ae06706
Author: thomasanderson <thomasanderson@google.com>
Date: Tue May 09 04:10:14 2017

Linux native notifications: Escape body text if body-markup is supported

This CL makes NotificationPlatformBridgeLinux follow Ubuntu's Notification
Development Guidelines:
https://wiki.ubuntu.com/NotificationDevelopmentGuidelines

BUG=676220
R=thestig@chromium.org

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

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

Project Member Comment 51 by bugdroid1@chromium.org, May 9
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c3b7ae8000d7222d74e2d0942d1d8823ecc0fd52

commit c3b7ae8000d7222d74e2d0942d1d8823ecc0fd52
Author: thomasanderson <thomasanderson@google.com>
Date: Tue May 09 05:33:03 2017

Linux native notifications: use image_path instead of image-path for spec 1.1

You're supposed to use 'image_path' for notification servers that only
support the FDO Notification spec version 1.1, and 'image-path' for
versions >= 1.2.  ¯\_(ツ)_/¯

Also, ban servers that have a spec version <= 1.0 because these won't
support notification icons at all.

BUG=676220
R=thestig@chromium.org

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

[modify] https://crrev.com/c3b7ae8000d7222d74e2d0942d1d8823ecc0fd52/chrome/browser/notifications/notification_platform_bridge_linux.cc
[modify] https://crrev.com/c3b7ae8000d7222d74e2d0942d1d8823ecc0fd52/chrome/browser/notifications/notification_platform_bridge_linux_unittest.cc
[modify] https://crrev.com/c3b7ae8000d7222d74e2d0942d1d8823ecc0fd52/tools/metrics/histograms/enums.xml

Project Member Comment 52 by bugdroid1@chromium.org, May 10
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bb3a8148c6f47151d82b7b9e490d8157d5e1fa6d

commit bb3a8148c6f47151d82b7b9e490d8157d5e1fa6d
Author: thestig <thestig@chromium.org>
Date: Wed May 10 12:25:14 2017

Linux native notifications: Localize settings button.

BUG=676220

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

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

Project Member Comment 54 by bugdroid1@chromium.org, May 11
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4e5beb03dc2aed6e11e4ea8acf8ce8e77e10c08e

commit 4e5beb03dc2aed6e11e4ea8acf8ce8e77e10c08e
Author: thestig <thestig@chromium.org>
Date: Thu May 11 01:22:35 2017

Linux native notifications: Add const variables for DBus strings.

BUG=676220

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

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

Would it be possible to set the X Urgency window hint when a notification is sent? This way a windowmanager (i3 in my case) can highlight the desktop chrome is running on.
> Would it be possible to set the X Urgency window hint when a notification is sent? This way a windowmanager (i3 in my case) can highlight the desktop chrome is running on.

Not sure that's possible.  If you have multiple tabs to the same origin in different browser windows, we can't be sure which window sent the notification.

I think we would be unlikely to make such a change anyway.. :(
Did native notifications stop working for anyone?  The CL in c#51 whitelists servers that support an FDO spec version of at least 1.1 (which should be all of them).

Our metrics currently show that this has disabled native notifications for a significant portion of users.  If anyone is affected by this, can you please post the output of:
$ dbus-send --session --dest=org.freedesktop.Notifications --type=method_call --print-reply=literal /org/freedesktop/Notifications org.freedesktop.Notifications.GetServerInformation

For example, my machine outputs:
gnome-shell   GNOME   3.10.4   1.2
xfce4-notifyd claims it only supports spec 0.9.

GetServerInformation output:
Xfce Notify Daemon   Xfce   0.3.6   0.9
c#60  Thanks, that would explain it!
X-reffing images for https://codereview.chromium.org/2876603004


Screenshot from 2017-05-15 14:57:00.png
11.8 KB View Download
Screenshot from 2017-05-15 14:57:03.png
24.4 KB View Download
Screenshot from 2017-05-15 14:58:28.png
12.3 KB View Download
Screenshot from 2017-05-15 14:58:33.png
23.0 KB View Download
Project Member Comment 65 by bugdroid1@chromium.org, May 18
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6f8167514ca5a2fc2235cd4694f60598cd49bbf6

commit 6f8167514ca5a2fc2235cd4694f60598cd49bbf6
Author: thomasanderson <thomasanderson@chromium.org>
Date: Thu May 18 22:36:50 2017

Linux native notifications: Remove spec_version check

The spec version check was added to blacklist servers that don't
support icons.  However, some servers like xfce4-notifyd list a spec
version that doesn't have icons when the server actually does support
icons.  More context can be found on:
https://codereview.chromium.org/2883983004/

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

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

[modify] https://crrev.com/6f8167514ca5a2fc2235cd4694f60598cd49bbf6/chrome/browser/notifications/notification_platform_bridge_linux.cc
[modify] https://crrev.com/6f8167514ca5a2fc2235cd4694f60598cd49bbf6/chrome/browser/notifications/notification_platform_bridge_linux_unittest.cc
[modify] https://crrev.com/6f8167514ca5a2fc2235cd4694f60598cd49bbf6/tools/metrics/histograms/enums.xml

Project Member Comment 66 by bugdroid1@chromium.org, May 18
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/49db099a77be5b377b63e41373840a2b8413e6ff

commit 49db099a77be5b377b63e41373840a2b8413e6ff
Author: thomasanderson <thomasanderson@chromium.org>
Date: Thu May 18 22:49:46 2017

Linux native notifications: Require 'actions' and 'body' capabilities

Actions and body text are necessary and expected to be available for
web notifications, so blacklist servers that don't support them.  The
conditions for using native notifications are described at the end of
[1] (Google-only).

[1] https://docs.google.com/a/google.com/document/d/1cqXPpIyCf1RaEYx9XCPjZbO6U5oDeyslajznnG9wd_U/edit?usp=sharing

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

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

[modify] https://crrev.com/49db099a77be5b377b63e41373840a2b8413e6ff/chrome/browser/notifications/notification_platform_bridge_linux.cc
[modify] https://crrev.com/49db099a77be5b377b63e41373840a2b8413e6ff/chrome/browser/notifications/notification_platform_bridge_linux_unittest.cc

Why blacklist notification daemons that don't allow actions?

If a user explicitly chose not to have actions, chromium shouldn't ignore that user preference, and just show its own notifications. The whole point of this integration is to respect the users preference and integrate with their notification daemon of choice, not impose the dev's preferences.
Both Chrome (for configurability of permissions) and various web applications rely on the availability of actions. While user choice definitely is a good thing, we also need to make sure our behaviour continues to be consistent enough to provide a good interoperability story to developers.
So .. developers' wishes are more important than users'?
That's exactly my point: you're saying that what developers want is what matters the most, and TBH, I completely disagree. If a user chose notifications with no actions, you shouldn't force the opposite on him just to satisfy developers.

If the user's choice is completely overriden, then there's no choice any more.
Not at all, but I do feel that there needs to be a balance between all parties. Based on excellent research done by Tom, metrics gathered through early users of this feature on Linux and expectations developers have based on the other notification centers supported by browsers we're intending to define a bottom line in regards to functionality. 

Effectively this comes down to {title, body, actions}, where almost all servers also support an icon. If there's support for additional features we'll progressively enhance to use that too.
I agree that there needs to be a balance between parties. Completely ignoring user preference is not a balance. Recommending that they use a daemon with actions is actually a balance (follow their preference, but recommend why something else might fit better).

Again, you're quoting developer expectation. It's nice to consider developer expectations when working on a feature, but it's not nice to override end-user preference merely to suite those expectations.

I don't really see any reason why you can't not-show actions to users who've explicitly opted to not-have actions on their notifications. (also, the doc that specifies why these decisions are made seem to be private).
On a more practical note; ignoring the notification daemon if the server doesn't allow actions will only result in one thing: someone hacking a server so that it CLAIMS to support actions, but does not (eg: alter notify-osd to show that capability). This is extremely trivial, and will only result in:

1. Users still having their preference respected, but,
2. Applications being unable to determine what that preference is.
Cc: miguelg@chromium.org
Project Member Comment 75 by bugdroid1@chromium.org, Jun 2
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ba0a42d0d3c05a9b9e5b125436e29b4a114b115f

commit ba0a42d0d3c05a9b9e5b125436e29b4a114b115f
Author: miguelg <miguelg@chromium.org>
Date: Fri Jun 02 18:56:18 2017

Don't display a settings button for extension notifications

BUG=676220

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

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

What is the current status on this ? Is there a working state i can use yet ? 
Yeah, but it's guarded behind a flag.  To enable it, go to chrome:flags, search for "enable native notifications" and set it to enabled.
Cc: willhopkins@google.com balro...@gmail.com mwortham@google.com liyanhou@chromium.org
 Issue 392448  has been merged into this issue.
Just created an issue which is related to this work:
https://bugs.chromium.org/p/chromium/issues/detail?id=739851

Thanks for adding support for native notifications!
The icon and image do not appear in my case. I'm not sure what the badge setting is supposed to do, though.

Browser: Chrome 59.0.3071.104
Desktop: KDE Plasma 5.10
Screenshot_20170708_154548.png
176 KB View Download
It is rather odd behavior that the default action opens settings rather than focusing the tab.
I run chrome beta (60), and I get icons and Gmail opens when I click on an
notification from Gmail etc.

Den lör 8 juli 2017 19:03tng… via monorail <
monorail+v2.2349933353@chromium.org> skrev:
c#80: Icons and images were not implemented in Chrome 59.  They definitely work in 61 (dev) and probably 60 (beta)

c#81: Known issue fixed in 60.  This was  bug 739851 
On GNOME (or any DE that's notifications support 'body-markup' for that matter) you need to escape the body of the notification. Currently you are not. 
c#84: Already fixed in chrome beta or dev
Given the last couple round of comments, if there are problems with notifications in version 59 or 60, please considering trying version 61 or 62 first before reporting them. Chances are, newer versions already fixed the problems.
> Icons and images were not implemented in Chrome 59.  They definitely work in 61 (dev) and probably 60 (beta)

Confirmed that icons work in 60 (Stable); however, images and badges still don't seem to work.
Sign in to add a comment