GNOME Bugzilla – Bug 663992
Timing issue with respect to reported states
Last modified: 2012-08-15 09:43:26 UTC
Created attachment 201332 [details] test script Steps to reproduce: 1. Launch the attached test script in one xterm 2. Launch gedit in another xterm 3. Quit gedit and relaunch it repeated Expected results: Each time the gedit window appears, the test script would print 'True' to indicate the Gedit text widget was focused at the time the focus: event was being processed. Actual results: Most of the time when the gedit window appears, the test script prints 'False' because the Gedit text window lacks STATE_FOCUSED at the time the focus: event is being processed. However, if you keep performing the test a sufficient number of times, you will see 'True' printed on occasion. This seems to be some sort of timing issue rather than an accessibility issue present in the widget itself.
I've made libatspi set the FOCUSED state on an object before reporting a focus event on it. This seems like a bit of a hack, and I'd like to figure out why we sometimes don't get state-changed:focused events in the first place, but I've committed for the sake of having something working in time for the stable release, but only to the gnome-3-2 branch so far.
Looking at the commit: http://git.gnome.org/browse/at-spi2-core/commit/?h=gnome-3-2&id=a0af0bcb79087fc16328cfe69a6845040d504bd1 There are something that worries me. It doesn't look at all with detail1. That means that it doesn't matter if it is a focus-in or a focus-out, and that it will claim the focus always. Or, am I missing anything?
(In reply to comment #2) > Looking at the commit: > http://git.gnome.org/browse/at-spi2-core/commit/?h=gnome-3-2&id=a0af0bcb79087fc16328cfe69a6845040d504bd1 > > There are something that worries me. It doesn't look at all with detail1. That > means that it doesn't matter if it is a focus-in or a focus-out, and that it > will claim the focus always. Or, am I missing anything? If you are not missing anything.... The problem becomes that at least in the case of Gtk+, we get focus: events with detail1 == 0 when something is claiming focus and no focus: event (just object:state-changed:focused) when focus is being given up. But this documentation suggests that what Gtk+ is doing might be odd/different: http://developer.gnome.org/atk/stable/AtkObject.html#AtkObject-focus-event Thus my concern is what will this change do in the case of a toolkit which is emitting focus: events both to indicate a focus gain and a focus loss (indicating the type with detail1)?
atk-bridge doesn't listen for focus-event signals. It listens for focus tracker notifications. It sends a "focus" event when it receives one of these. A focus tracker notification (registered through atk_add_focus_tracker) gets called with just an atk object and no detail. The focus tracker in atk-bridge sends the "focus" event over D-Bus and always puts 0 in the detail. Gtk has code that listens for focus-event signals on an atk object and, upon receiving them, emits state-changed:focused events on the same object. Anyway, Joanie is reporting that some applications send "focus" events with the detail1 set to 0 or 1 depending on whether the widget has gained or lost focus (I can't see how this could be happening with atk-bridge, but QT AT-SPI may well behave differently), so I'll plan on reverting the change and making a new release.
Hy Mike, Why need prewious revert the committed change? Doesn't working proper the committed fix? If future this bug is fixed, resolving focusing issue for example with GTK file selection dialogs? For example, if Gedit I would like saving a file, now the default text doesn't selected and focused I think. If I would like moving the caret the entry field, I need press SHIFT+TAB and TAB keys. I don't no this is happening visual or not, but Orca begin spokening me the default text field awailable characters if I doing this key presses. Oldest GNOME2 release happened following think if I doed a save as operation for example in gedit: Present the file selection dialog, and the caret jumps automaticaly the name entry field. If I using left or right arrow keys, Orca wonderful spokened the highlighted character. Have a schedule what at-spi2-atk release will be fixed this bug? Attila Attila
I've made a "focus" event invalidate the object's cached states. This seems to fix it. Really should find the root of the problem but don't have time to investigate more right now.
*** Bug 659454 has been marked as a duplicate of this bug. ***