1236153 - Clicking libnotify popups does not raise Firefox

Status: NEW

(Toolkit :: Alerts Service, defect)

Description

[Jan Alexander Steffens [:heftig]]

Clicking the notification as created by the "Notify me!" button on https://developer.mozilla.org/en-US/docs/Web/API/notification just causes another notification from the shell that the Firefox window "is ready", instead of immediately raising the window into the foreground.

Bizarrely, when Quassel IRC is running, the Quassel window is raised instead. The "is ready" notification still happens.

libnotify notifications from other (non-Mozilla) applications seem to behave properly, as does clicking XUL notifications when libnotify is disabled using the Disable System Alerts addon.

Reproduced with:
Arch's Firefox 43.0.1 (GTK3)
My FDE 45.0a2 (git 4697d2c)
Nightly 46.01a (2016-01-01-03-03-30-mozilla-central 22f51211915bf7daff076180847a7140d35aa353)

Arch Linux x86_64
GNOME Shell 3.18.3
libnotify 0.7.6

Comment 1

[Jan Alexander Steffens [:heftig]]

GNOME bug: https://bugzilla.gnome.org/show_bug.cgi?id=760048

Comment 2

[Lina Butler [:lina]]

Matt and I looked at this a few months back. IIRC, Matt told me it had something to do with either the GTK window or notification timestamp. We did some investigating, but couldn't create a reduced test case with a simple app, and then other projects came up.

Comment 4

[Jan Alexander Steffens [:heftig]]

My guess is that the shell expects a timestamp to go with the raise request that matches the click on the notification. However, the notification service provides no such timestamp.

The quassel issue was in fact unrelated (
https://github.com/quassel/quassel/pull/272/commits/38112a9e19283aa6768df9af14503ccbe09fe5b0). I wonder what Quassel does that makes the shell heed its raise request for an unrelated notification.

Comment 5

[Karl Tomlinson (:karlt)]

Attachment: xrecord x communication logging program

Yes, it's not possible to do the right thing when the protocol does not
provide a timestamp, but it could be helpful to know what other apps do
that results in their raise requests being accepted.

This program can be compiled and run without arguments, to log some
communication with the window manager.
The client ids output correspond to resource bases in output from
"xrestop -b -m 1".

Look for _NET_ACTIVE_WINDOW requests for focus.  The last hex number on the
line is the timestamp in the request.
WM_PROTOCOLS protocol=WM_TAKE_FOCUS is sent when focus is granted with a
timestamp.

Firefox uses an old timestamp in _NET_ACTIVE_WINDOW, because it doesn't have a
newer one.

I'm curious what other apps use.

If the window manager has no explicitly active window (because the last click
was on a notification window, which either didn't take focus or is closed),
then perhaps it is more gracious about granting focus requests with timestamps
of 0.

Comment 6

[Martin Stránský [:stransky] (ni? me)]

A good example is Xchat - it uses libnotify and raises its window when the notification is clicked. I'll look into it how xchat sets the notify code.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

(In reply to Karl Tomlinson (:karlt) from comment #5)
> I'm curious what other apps use.

Looks like other apps do not call notify_notification_add_action() which means the click is handled by default handler which pop-ups the app window. The same works for Firefox when notify_notification_add_action() is commented out. Unfortunately the default handler raises last active app window and it's unusable for us.

Comment 8

[Jan Horak [:jhorak]]

It looks like wmctrl use _NET_ACTIVE_WINDOW with zero timestamp and it seems to work well. There's the relevant code:

https://pastebin.mozilla.org/8981503

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Well, the 0 timestamp is accepted by mutter with some complains:

VERBOSE: _NET_ACTIVE_WINDOW request for window '0x1c00010 (1236153 â<80><93> )', activating
Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x1c00010 (1236153 â<80><93>
FOCUS: _NET_ACTIVE_WINDOW message sent for 0x1c00010 (1236153 â<80><93> ) at time 0 by client type 0.
STARTUP: Window 0x1c00010 (1236153 â<80><93> ) has _NET_WM_USER_TIME of 21855969
WINDOW_OPS: Raising window 0x1c00010 (1236153 â<80><93> ), ancestor of 0x1c00010 (1236153 â<80><93> )

OTOH The old timestamp is always refused by mutter:

STACK: Ignoring xconfigure stacking request from 0x1a0005e (HTML5 Web ) (with user_time 12355898); currently active application is 0x18004ad (komat@dhcp) (with user_time 12356802).
WINDOW_OPS: Marking 0x1a0005e (HTML5 Web ) as needing attention
VERBOSE: _NET_ACTIVE_WINDOW request for window '0x1a0005e (HTML5 Web )', activating
FOCUS: _NET_ACTIVE_WINDOW message sent for 0x1a0005e (HTML5 Web ) at time 12355898 by client type 1.
FOCUS: last_user_time (12356802) is more recent; ignoring  _NET_ACTIVE_WINDOW message.

So the "HTML5 Web" which is FF here is just marked as "Needed attention" and another notification is sent.

Comment 10

[Martin Stránský [:stransky] (ni? me)]

There's a try-build:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=657413eb9516db470a27f2297d780ac48b561155&selectedJob=83054414

with this patch:
https://hg.mozilla.org/try/rev/657413eb9516db470a27f2297d780ac48b561155

where we always focus with GDK_CURRENT_TIME.

Karl, any idea in which case we call SetFocus() with old timestamp and that's actually correct?

Comment 11

[Jan Alexander Steffens [:heftig]]

I'm pretty sure that's done during remoting, so that the existing Firefox instance can obtain focus. It may also affect initial startup. I'd follow the code using the DESKTOP_STARTUP_ID.

Applied that patch to my own build; unfortunately, it didn't improve the notification behavior but broke focus from remoting.

For the record, I also tried using SetFocusTimestamp(gtk_get_current_event_time()) in the notification action callback, to no effect.

Comment 12

[Martin Stránský [:stransky] (ni? me)]

(In reply to Jan Steffens from comment #11)
> I'm pretty sure that's done during remoting, so that the existing Firefox
> instance can obtain focus. It may also affect initial startup. I'd follow
> the code using the DESKTOP_STARTUP_ID.
> 
> Applied that patch to my own build; unfortunately, it didn't improve the
> notification behavior but broke focus from remoting.

That's interesting. Which DE/distro do you run?

Comment 13

[Jan Alexander Steffens [:heftig]]

GNOME 3.22 on Arch Linux.

Comment 14

[Martin Stránský [:stransky] (ni? me)]

I see that too, strange that the same patch was working yesterday flawlessly.

Comment 15

[Martin Stránský [:stransky] (ni? me)]

(In reply to Karl Tomlinson (:karlt) from comment #5)
> I'm curious what other apps use.
> 
> If the window manager has no explicitly active window (because the last click
> was on a notification window, which either didn't take focus or is closed),
> then perhaps it is more gracious about granting focus requests with
> timestamps
> of 0.

Well, on gnome-shell the notification-daemon is a part of gnome-shell. When the notification bubble is clicked on the gnome-shell (notification server) raises related app by direct mutter call meta_workspace_activate_with_focus() unless there's a "default" "Activate" callback registered by app.

On the firefox side the "default" "Activate" callback is handled by "DOMWebNotificationClicked" event in tabbrowser.xml which calls window.focus() only.

I see some ways how to handle this:

1) try to register different handler (not the "Activate" one) at libnotify and leave mutter to activate the app for us. That may lead to wrong window raise as the notification server does not know which FF window sent the notification.

2) update the "DOMWebNotificationClicked" event handler to also raise window (not only focus()). Not sure it's feasible/possible.

3) report bugs agains gnome-shell and other DE to activate the application even when the "Activate" callback is registered by app.

Comment 16

[Kagami Rosylight [:saschanaz] (they/them)]

libnotify is platform specific: