Open Bug 1236153 Opened 5 years ago Updated 8 months ago

Clicking libnotify popups does not raise Firefox

Categories

(Toolkit :: Notifications and Alerts, defect)

Unspecified
Linux
defect
Not set
normal

Tracking

()

People

(Reporter: heftig, Unassigned)

References

Details

Attachments

(1 file)

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
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Duplicate of this bug: 1225387
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.
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.
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.
(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.
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
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.
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?
Flags: needinfo?(karlt)
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.
(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?
Flags: needinfo?(jan.steffens)
GNOME 3.22 on Arch Linux.
Flags: needinfo?(jan.steffens)
I see that too, strange that the same patch was working yesterday flawlessly.
Flags: needinfo?(karlt)
See Also: → 392721, 721498
(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.
You need to log in before you can comment on or make changes to this bug.