After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 647275 - Opening messages in Evolution and Empathy doesn't focus the window
Opening messages in Evolution and Empathy doesn't focus the window
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
3.0.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 647165 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-04-09 13:47 UTC by Jean-François Fortin Tam
Modified: 2011-04-12 17:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GdkDeviceManagerXI2: don't set user_time on ButtonRelease (1.07 KB, patch)
2011-04-11 17:27 UTC, Dan Winship
accepted-commit_now Details | Review
gtk_window_present_with_time: fix when window is not initially visible (2.43 KB, patch)
2011-04-11 17:27 UTC, Dan Winship
needs-work Details | Review
gtk_window_present_with_time: fix when window is not initially visible (2.90 KB, patch)
2011-04-12 14:23 UTC, Dan Winship
accepted-commit_now Details | Review

Description Jean-François Fortin Tam 2011-04-09 13:47:14 UTC
To reproduce, double-click a message in your evolution inbox.

Result: an "Evolution is ready" notification is shown instead of showing the window I just called.

This wasn't a problem in gnome 2.32.

Also, when clicking a URL in empathy, the same thing happens with Firefox (it doesn't come into focus), but I guess that one is intentional.
Comment 1 Jean-François Fortin Tam 2011-04-10 15:24:20 UTC
Same problem with Empathy: double-click someone on your contact list and the chat window will appear in the background instead of being focused.
Comment 2 Dan Winship 2011-04-11 13:46:15 UTC
*** Bug 647165 has been marked as a duplicate of this bug. ***
Comment 3 Dan Winship 2011-04-11 17:27:24 UTC
I am not able to explain why this doesn't happen under metacity, but under gnome-shell it is caused by two gtk bugs.
Comment 4 Dan Winship 2011-04-11 17:27:54 UTC
Created attachment 185739 [details] [review]
GdkDeviceManagerXI2: don't set user_time on ButtonRelease

The XI2 device manager was mistakenly setting the window user_time on
both ButtonPress and ButtonRelease, which meant that processes that
tried to launch another process based on the time of a ButtonPress
event would end up always focus-stealing-preventing the new app.
Comment 5 Dan Winship 2011-04-11 17:27:57 UTC
Created attachment 185740 [details] [review]
gtk_window_present_with_time: fix when window is not initially visible

When called on a hidden window, gtk_window_present_with_time() would
just fall back to gtk_widget_show(), completely ignoring the passed-in
timestamp. This ended up working anyway if the timestamp came from
in-process, since gdk_window_x11_show() would initialize its user_time
from the time of the most recent event. But if the timestamp came from
another process, this would result in the window being shown with an
out-of-date timestamp.

Fix this by explicitly setting the GdkWindow's user_time before it
gets mapped.
Comment 6 Owen Taylor 2011-04-11 18:19:05 UTC
Review of attachment 185740 [details] [review]:

Wow, weird, looks like it was broken from day 0 for the 2.8 cycle and nobody ever noticed that timestamp passing didn't work.

::: gtk/gtkwindow.c
@@ +7391,3 @@
     {
+#ifdef GDK_WINDOWING_X11
+      gtk_widget_realize (widget);

This breaks the optimization of only realizing windows after they have been allocated to avoid resizing all the GDK windows. This is much less important with client side windows, but still a small factor.

But beyond that, force-realization in a normal code path triggered inside GDK strikes me as ugly. Maybe better to expand GtkWindow with a saved timestamp? (What's 4 more bytes...)
Comment 7 Matthias Clasen 2011-04-11 22:36:14 UTC
Review of attachment 185739 [details] [review]:

Looks right. Good catch
Comment 8 Matthias Clasen 2011-04-11 22:37:49 UTC
Review of attachment 185740 [details] [review]:

Can you rework this patch as Owen proposes ?
I've just saved some space in GtkWindowPrivate, so adding a timestamp field should be ok...
Comment 9 Matthias Clasen 2011-04-11 22:39:39 UTC
Review of attachment 185740 [details] [review]:

Setting patch status
Comment 10 Dan Winship 2011-04-12 14:23:29 UTC
Created attachment 185793 [details] [review]
gtk_window_present_with_time: fix when window is not initially visible

Fixed according to Owen's suggestion. Much simpler this way.
Comment 11 Matthias Clasen 2011-04-12 16:52:50 UTC
Review of attachment 185793 [details] [review]:

Looks good to me.