GNOME Bugzilla – Bug 732141
New message notifications behave poorly (spawn unnecessary second notification, do not jump to appropriate folder or message)
Last modified: 2021-07-05 14:16:48 UTC
I don't know if this is an Evo bug or a GNOME Shell one - filing against Evo with the possibility of being re-assigned. For the last few Evolution / GNOME Shell releases, new message notifications behave pretty badly. Here's what happens: 1. I get a new mail. 2. Evo pops up a notification that I have a new mail. 3. I click on the notification. 4. This generates *another* notification, saying that the Evolution window is ready. 5. I click on this second notification and Evolution's main window comes to the foreground, but it does not select the new mail that just arrived, or even the appropriate folder. It just stays in whatever state it was in before. I would expect that clicking on the *first* notification would activate Evo's main window, and probably jump to the appropriate folder / message. This is on Fedora Rawhide - Evo 3.12.3, GNOME Shell 3.13.2 - but I'm fairly sure it's been going on for some time now, might even be valid in Fedora 20 with 3.10.
Created attachment 279079 [details] XFCE notification from Evolution 3.13 Seems to work fine outside of GNOME Shell.
Here's a video showing the current Rawhide experience: https://www.happyassassin.net/temp/evo_notification_shell.webm . The second notification doesn't always suddenly hide itself like that, not sure what happened there, but even without that wrinkle, it's bad enough). Note that when the Evo window finally appears, it doesn't bring up the new message or even the inbox folder.
FWIW, I traced the "is ready" message to gnome-shell: https://git.gnome.org/browse/gnome-shell/tree/js/ui/windowAttentionHandler.js#n19 Also worth noting is Evolution's notification code hasn't functionally changed in at least two years. There isn't really much to the notification code anyway. We prepare a notification structure with the text you see (with the urgency set to "normal"), and hand it off to notify_notification_show(). The default action handler for the notification presents the main window with gtk_window_present(), switches to the Mail view if necessary, and selects the folder mentioned in the notification. (Selecting the exact message has never worked, so that's not a regression.) I suspect the problem may be with the gtk_window_present() call. AFIAK that's still the right thing to do to raise the window on the appropriate screen / desktop and give it input focus. XFCE handles it correctly, but perhaps GNOME Shell is misinterpreting it. Thing is either a GNOME Shell bug or I need a GNOME Shell developer to tell us what we're doing wrong. Relevant code is here: https://git.gnome.org/browse/evolution/tree/plugins/mail-notification/mail-notification.c
(In reply to comment #0) > I don't know if this is an Evo bug or a GNOME Shell one - filing against Evo > with the possibility of being re-assigned. > > For the last few Evolution / GNOME Shell releases, new message notifications > behave pretty badly. Here's what happens: > > 1. I get a new mail. > 2. Evo pops up a notification that I have a new mail. > 3. I click on the notification. > 4. This generates *another* notification, saying that the Evolution window is > ready. > 5. I click on this second notification and Evolution's main window comes to the > foreground, but it does not select the new mail that just arrived, or even the > appropriate folder. It just stays in whatever state it was in before. > > I would expect that clicking on the *first* notification would activate Evo's > main window, and probably jump to the appropriate folder / message. Is your evolution window on a different workspace? (In reply to comment #3) > FWIW, I traced the "is ready" message to gnome-shell: > https://git.gnome.org/browse/gnome-shell/tree/js/ui/windowAttentionHandler.js#n19 > > Also worth noting is Evolution's notification code hasn't functionally changed > in at least two years. There isn't really much to the notification code > anyway. We prepare a notification structure with the text you see (with the > urgency set to "normal"), and hand it off to notify_notification_show(). > > The default action handler for the notification presents the main window with > gtk_window_present(), switches to the Mail view if necessary, and selects the > folder mentioned in the notification. (Selecting the exact message has never > worked, so that's not a regression.) > > I suspect the problem may be with the gtk_window_present() call. Well gtk_window_present() afaik does not pass a timestamp so it is the wrong thing to do for a user initiated action. A timestamp of 0 would trigger focus stealing prevention (in gnome-shell this is the "is ready" notification). It should use gtk_window_present_with_time () and pass a proper timestamp.
"Is your evolution window on a different workspace?" No. I do not use workspaces at all. Does the video not show the issue clearly?
(In reply to comment #4) > Well gtk_window_present() afaik does not pass a timestamp so it is the wrong > thing to do for a user initiated action. A timestamp of 0 would trigger focus > stealing prevention (in gnome-shell this is the "is ready" notification). It > should use gtk_window_present_with_time () and pass a proper timestamp. gtk_window_present() is just gtk_window_present_with_timestamp (window, GDK_CURRENT_TIME) gtk_window_present_with_time() substitutes GDK_CURRENT_TIME (0) with a valid timestamp. I don't think the timestamp is the problem.
(In reply to comment #6) > (In reply to comment #4) > > Well gtk_window_present() afaik does not pass a timestamp so it is the wrong > > thing to do for a user initiated action. A timestamp of 0 would trigger focus > > stealing prevention (in gnome-shell this is the "is ready" notification). It > > should use gtk_window_present_with_time () and pass a proper timestamp. > > gtk_window_present() is just > > gtk_window_present_with_timestamp (window, GDK_CURRENT_TIME) Yes and GDK_CURRENT_TIME is 0 ... which is not a valid timestamp. You should send a proper timestamp for a user initiated action. > gtk_window_present_with_time() substitutes GDK_CURRENT_TIME (0) with a valid > timestamp. Yes and that's what you should do to prevent focus stealing prevention from kicking in. > I don't think the timestamp is the problem. I am pretty sure it is. Its the only thing that could cause that.
(In reply to comment #7) > (In reply to comment #6) > > > > gtk_window_present() is just > > > > gtk_window_present_with_timestamp (window, GDK_CURRENT_TIME) > > Yes and GDK_CURRENT_TIME is 0 ... which is not a valid timestamp. You should > send a proper timestamp for a user initiated action. The obvious problem here is that neither the libnotify, nor the GNotification API pass any timestamp applications could use. > > I don't think the timestamp is the problem. > > I am pretty sure it is. Its the only thing that could cause that. I don't know, if I recall correctly, we have always accepted 0 as timestamp for windows on the active workspace (though we used to complain about it).
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > > > > gtk_window_present() is just > > > > > > gtk_window_present_with_timestamp (window, GDK_CURRENT_TIME) > > > > Yes and GDK_CURRENT_TIME is 0 ... which is not a valid timestamp. You should > > send a proper timestamp for a user initiated action. > > > The obvious problem here is that neither the libnotify, nor the GNotification > API pass any timestamp applications could use. > > > > > I don't think the timestamp is the problem. > > > > I am pretty sure it is. Its the only thing that could cause that. > > I don't know, if I recall correctly, we have always accepted 0 as timestamp for > windows on the active workspace (though we used to complain about it). Yeah that's why I asked Adam whether he uses multiple workspaces he said no but that's not really true because he is on multi monitor where each monitor has a worksapce ... so if the right monitor is active it counts as a "not active workspace" ? So we should probably special case this one.
(In reply to comment #9) > Yeah that's why I asked Adam whether he uses multiple workspaces he said no but > that's not really true because he is on multi monitor where each monitor has a > worksapce ... so if the right monitor is active it counts as a "not active > workspace" ? Workspaces are per-screen, not per-monitor. However if workspaces-only-on-primary is set, the window may actually be on a different workspace? Though I'd be a bit surprised if we really didn't handle on-all-workspaces already ...
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > > > > gtk_window_present() is just > > > > > > gtk_window_present_with_timestamp (window, GDK_CURRENT_TIME) > > > > Yes and GDK_CURRENT_TIME is 0 ... which is not a valid timestamp. You should > > send a proper timestamp for a user initiated action. > > The obvious problem here is that neither the libnotify, nor the GNotification > API pass any timestamp applications could use. Right, and fabricating our own timestamp would only replicate what gtk_window_present_with_time() already does with GDK_CURRENT_TIME: https://git.gnome.org/browse/gtk+/tree/gtk/gtkwindow.c#n9871
(In reply to comment #10) > (In reply to comment #9) > > Yeah that's why I asked Adam whether he uses multiple workspaces he said no but > > that's not really true because he is on multi monitor where each monitor has a > > worksapce ... so if the right monitor is active it counts as a "not active > > workspace" ? > > Workspaces are per-screen, not per-monitor. However if > workspaces-only-on-primary is set, the window may actually be on a different > workspace? That's what I meant. > Though I'd be a bit surprised if we really didn't handle > on-all-workspaces already ... Adam can you reproduce this with just one monitor?
drago01: oh, sorry, I didn't realize the second head counted as a workspace. I'll test if the bug occurs with only one.
note that the notification appears on the same head as the Evo window, though.
(In reply to comment #14) > note that the notification appears on the same head as the Evo window, though. The notification is always on primary that does not mean much.
(In reply to comment #12) > (In reply to comment #10) > > However if workspaces-only-on-primary is set, the window may actually > > be on a different workspace? > > That's what I meant. Looking at the code[0], it should work correctly though ... [0] https://git.gnome.org/browse/mutter/tree/src/core/window.c#n1466
Created attachment 279333 [details] screencast of a notification with a single head and single workspace Yes, it still appears to happen with a single active head and a single workspace. See video. (The correct folder is only displayed when Evo appears because it was already selected beforehand).
oops, the video shows a private email, but I don't think it's anything the correspondent would mind being visible. I'll double check with him.
Is this still an issue?
well, I just got a notification and forgot to click on it while it was showing, so I opened the notifications box and clicked on it and it just disappeared without activating the Evolution window at all. Next time I get a notification I'll see what happens if I click on it while it's initially visible.
When clicking a notification when it first appears, with Evo 3.23.2 and GNOME Shell 3.23.1 , the behaviour is still as described in this report: clicking first notification produces a second 'Evolution window is ready' notification, clicking that switches to Evo but does not open the relevant folder or mail.
This looks like a dupe of *** This bug has been marked as a duplicate of bug 741014 ***
Well it was filed 6 months earlier, but sure, I guess?
I think I just got those the wrong way around somehow, and this one has more info, so it's the keeper!
*** Bug 741014 has been marked as a duplicate of this bug. ***
*** Bug 750031 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.