GNOME Bugzilla – Bug 347481
Focus grab needs to update window timestamp to grab focus
Last modified: 2007-03-22 07:20:18 UTC
Please describe the problem: On using at-spi API AccessibleComponent_grabFocus, the window does not appear in foreground. Using LDTP we can easily reproduce the bug. Steps to reproduce: Run the following command in python prompt after installing LDTP 1. from ldtp import * 2. grabfocus ('*-gedit', 'txt0') 3. Actual results: Window just blinks in the task bar. Window focus still stays with the terminal in which I executed the steps. Expected results: Grabed window should be in focus. Does this happen every time? Always Other information: Steps to install LDTP http://ldtp.freedesktop.org/wiki/Downloads
This functionality was working till GNOME 2.8. From GNOME 2.10, some change in metacity have changed the expected result.
This is not an at-spi bug, it's a result of metacity's "focus stealing prevention". Closing as NOTABUG, though if you feel you need the ability to bring a window to the front in LDTP I suggest you talk to the metacity developers or the wm-spec-list to find out the right way to do it. I don't really see this as something AT-SPI should provide (bringing windows to the front) - at the moment GOK achieves this via libwnck. But I suppose adding the "bring to front on activate" behavior to AT-SPI for objects of ROLE_FRAME would be a reasonable RFE.
Bill, shouldn't it be the task of the a11y framework to keep up with changes like this? In other words, shouldn't whatever endpoint the current code has (presumably a call in ATK), be modified to update the timestamp, so that the focus is properly grabbed? This seems like something that should work the same for all apps that use the a11y framework, rather than something we should try to work around with special case code in each app. If there's an API call to grab focus, then it should continue to work, even if the circumstances it must work under, change slightly. Sounds to me like AccessibleComponent_grabFocus or whatever it calls in ATK/etc... just needs to be updated to update the timestamp on the window somehow.
In order to do what Rodney suggests, we would need to obtain a legal timestamp when fulfilling the call. X doesn't provide API for doing that, so we'd need some way to obtain a 'current' timestamp from the xserver. Not sure exactly how to get this however - possibly some XPropertyChange call or something, whose resulting event we trap? It could be ugly unless we can make that somehow synchronous.
Is time (NULL) not good enough? Is there not some way to get a GdkEvent which has a timestamp in it? (If this needs to go into ATK, I understand not being able to use GdkEvent) Maybe some metacity hackers could chime in?
In order to obtain a 'current' timestamp from the server, you can use the code from gtk+/gdk/x11/gdkevents-x11.c:gdk_x11_get_server_time or metacity/src/display.c:meta_display_get_current_time_roundtrip.
Created attachment 79926 [details] [review] Grab focus patch Bill, Verified the patch with gailwidget.c. Need to check gailtreeview.c and gailcanvasitem.c. gailwidget.c works perfectly fine. Waiting for your review. Thanks
Comment on attachment 79926 [details] [review] Grab focus patch looks good - do we need to increment the version dependency for gtk+? i.e. when did the ...present_with_time API get added?
According to the doc in http://developer.gnome.org/doc/API/2.0/gtk/GtkWindow.html#gtk-window-present-with-time it has been there since 2.8. Already gail's requirement of GTK+ is GTK_REQUIRED_VERSION=2.9.4 in SVN. I guess no change is required.
Bill: ping :)
We should ask the list (g-a-d) whether clients think grabFocus should pop the window to the top, even when called on a subcomponent (as opposed to just a toplevel window).
reassign to Li Yuan
patch committed into HEAD.