I can't generate a notification with a timeout using the tool, but I suspect that if the notification is generated while the browser is in use, it disappears the next time you click on the browser, potentially long before you've seen it.

Tested w/ the hangouts extension. It disappears if you switch Chrome windows, but not tabs.

Unable to reproduce the issue on Ubuntu 14.04 using chrome reported version #64.0.3282.85(beta) and latest dev #65.0.3315.3.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Created a persistent notification here: https://tests.peter.sh/notification-generator/
2. Clicked on a non-Chrome application.
3. Clicked on any Chrome window.
4. Observed that notification persisted as expected.

josephcohen@ - Could you please check this issue on latest dev #65.0.3315.3 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Deleted: 801689.ogv 2.8 MB

	801689.ogv 2.8 MB View Download

The issue persists for me. But In my browser version system notifications are used instead of Chrome generated notifications.
Also, now they're disappearing quickly again (a few seconds after I create them.)

Deleted: Screenshot from 2018-01-16 07-18-19.png 21.3 KB

	Screenshot from 2018-01-16 07-18-19.png 21.3 KB View Download

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

josephcohen@ for better understanding of this issue could you please help us with the screen-cast of this issue and expected behavior.

Thanks...

Marking this as public.

krajshree: Have you disabled native notifications somehow? Please make sure that they're enabled in chrome://flags too.

Able to reproduce this issue on Ubuntu 14.04 using chrome reported version #64.0.3282.85, latest chrome stable #64.0.3282.119 and latest chrome version #66.0.3335.0.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

I believe the behavior of when a notification disappears is up to the native notification daemon running on your system. For example, I use dunst as my notification daemon, and notifications never disappear unless I tell them to.

If you are using Cinnamon as your DE (which is looks like you are), then it is up to the Cinnamon notification daemon to decide when to dismiss the notification. I would assume that is sees you are activating a Chrome window, and that the notification is for Chrome, and so it dismisses the notification. I doubt that the daemon would be able to tell that a notification came from the Hangouts extension, and so should only be dismissed when Hangouts is activated, for example.

Adding Tom for any potential extra information and/or to correct me.

kkaluri, Sorry I wasn't able to get you a screencast.

Tim, I believe your understanding is correct.

This is a design decision for Chrome Linux. Given the wide variety of daemons, and this (possibly undesirable) behavior with the default Cinnamon one, should Chrome Linux integrate with native Linux notifications?

If so, should Chrome re-create any notifications that are closed on Chrome focus (without being clicked) to prevent this behavior?

I'm currently trying to get upstream to change this behavior:
https://github.com/linuxmint/Cinnamon/pull/7252

This is also a problem with GNOME (tested with 3.26.2 on Fedora). But I think there is an easy fix.

In playing around with notify-send, I think we'd want to set the "resident" hint, which will not close the notification unless the small X is clicked. This also allows the web notifications API the choice on when to close the notification.

I can prepare a patch if that helps.

I'm attaching some screenshots from "notify-send -h int:resident:1 hello".

Deleted: 1-popup.png 13.3 KB

	1-popup.png 13.3 KB View Download

Deleted: 2-hover.png 13.9 KB

	2-hover.png 13.9 KB View Download

Deleted: 3-tray.png 34.9 KB

	3-tray.png 34.9 KB View Download

There is a problem with using "resident" on GNOME. If the notification is generated by the app that currently has focus, a banner will not display, only a small symbol. The notifications will be in the tray though.

This does highlight an interesting problem. Chrome is the vehicle for these notifications from web pages, but currently isn't able to convey this to dbus effectively. Dbus just sees Chrome as a single application.

See https://bugzilla.gnome.org/show_bug.cgi?id=630847#c20 for background.

Deleted: resident-focus-no-banner.png 4.2 KB

	resident-focus-no-banner.png 4.2 KB View Download

To fix this more generally, what about having a separate notification process that connects to dbus but never has focus?

This is more in line with how notifications are tied to background service workers, and would fix a lot of these focus problems without having to make upstream changes.

agoode: does removing the desktop-entry hint have the same effect?
https://cs.chromium.org/chromium/src/chrome/browser/notifications/notification_platform_bridge_linux.cc?rcl=280a408413bcffc6b6540f5dafe766ebad59d0af&l=645
lines 645-656

No, that doesn't make things better. See
https://github.com/GNOME/gnome-shell/blob/a6ff195893f6a6a215b5c75b93cc48c49375d46a/js/ui/notificationDaemon.js#L513

and

https://github.com/GNOME/gnome-shell/blob/a6ff195893f6a6a215b5c75b93cc48c49375d46a/js/ui/notificationDaemon.js#L519

The daemon uses get_app_from_pid() which uses the window manager to figure out which windows correspond to which pid. (There is an "app" abstraction in there that I don't know much about, so there are probably some nuances I am missing.)

But it looks like you really do need to have a separate pid to work around the focus detection mechanism.

Ok, that's interesting.  I'd like to avoid having a separate process just for notifications.

fwiw, we did land the fix in cinnamon
https://github.com/linuxmint/Cinnamon/commit/65c4cc1e0469b32e685c3029dc6b1df2d45e9a09
And we have a patch for GNOME
https://gitlab.gnome.org/GNOME/gnome-shell/issues/37
but it doesn't look like it's getting much attention

It's great to see the patches going upstream. And I agree having another process is annoying.

The patch looks good as a workaround, though the proper fix would probably involve a protocol change to make it easier to implement these kinds of proxies (or using a separate process in chrome).

The more I think about it, the more I think having a separate process is important for conveying the proper semantics to the notification system.

How much of a pain would it be? If it's not completely out of the question, I'd be willing to spend some time on this.

+peter

IMO, it would be more time-effective to just bug upstream to merge the patch instead of adding the complexity of a separate process for this, and I'd argue that adding a separate process is the workaround, not the upstream patches.

I would like to avoid introducing a separate process. That's a lot of complexity and imposes a high maintenance cost.

We already have a helper process on Windows for handling activations, and a background XPC service on Mac OS for displaying notifications that do not time out. Those carry similar costs, but for much larger groups of users.

The current approach of working with the notification servers feels like the right approach to me. We can revisit if we hit very strong blockers in this regard.

Is there a workaround for this issue? As far as I can tell, this essentially renders notifications completely broken for anybody who switches window focus frequently. This severely impacts important notification-based productivity applications like Google Calendar.

Are we really going to have to wait for upstream commits to land and get rolled out before browser based calendar tools are expected to be functional again?

This bug has caused myself and others to miss meetings. Given the general zeal towards making sure alert() based notifications are no longer "annoying", they too have been rendered useless for calendar notifications. So there is essentially no functioning mechanism to get alerts about important things like meetings. General commentary: Chrome has taken several steps backwards recently for the calendar use case... Maybe I am the exception, but I WANT obtrusive/blocking/annoying alerts for things which I decide are important enough to warrant notifications.

> Is there a workaround for this issue?

Yes.  In chrome://flags, set #enable-native-notifications to disabled.

If you restart Chrome, it will probably already be disabled, specifically because of this bug.