GNOME Bugzilla – Bug 647275
Opening messages in Evolution and Empathy doesn't focus the window
Last modified: 2011-04-12 17:03:59 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.
Same problem with Empathy: double-click someone on your contact list and the chat window will appear in the background instead of being focused.
*** Bug 647165 has been marked as a duplicate of this bug. ***
I am not able to explain why this doesn't happen under metacity, but under gnome-shell it is caused by two gtk bugs.
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.
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.
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...)
Review of attachment 185739 [details] [review]: Looks right. Good catch
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...
Review of attachment 185740 [details] [review]: Setting patch status
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.
Review of attachment 185793 [details] [review]: Looks good to me.