GNOME Bugzilla – Bug 163755
flat review interrupted by window:activate evens when pressing a key from numpad in gnopernicus
Last modified: 2006-06-14 15:29:17 UTC
Steps to reproduce: 1. Launch Gnopernicus Screen Reader and Brlmonitor. 2. Launch other application, such as Evolution. 3. Press NumLock key to open the NumLock. 4. Press '0' key in numpad twice and hear of report 'layer 0'. 5. Press 'Del' key in numpad and switch gnopernicus to 'flatreview mode'. 6. Press '2', '3' or '8' in numpad for several times to report the screen. Expected result: Gnopernicus can report the whole screen in flatreview mode successfully. Actual result: Gnopernicus fails to report the screen, it always switches to focus tracking mode after you press '2' for about 3 times.
This is happening because an unexpected event ('activate window' event) is generated when key'2' is pressed several times. Bug: http://bugzilla.ximian.com/show_bug.cgi?id=71198 was filed against evolution for this problem. I will close this bug as 'NOTGNOME' until the evolution bug is solved.
Re-opening, as there is not sufficient evidence that this is evolution's fault.
This is a regression. It is in fact bug #108664 which was never real fixed. *** This bug has been marked as a duplicate of 108664 ***
No, 108664 was fixed to the extent that it COULD be fixed. It appears from the bug report that there may be something specific about evolution which is causing the symptoms to be more severe, but we need more information about this; i.e. how rapidly must the numpad-2 key be pressed, in succession, in order to see this problem? Does flat review mode work properly if the key presses are slower? etc.
Created attachment 35948 [details] [review] proposed patch to prove this is not a gnopernicus bug Patch displays time spent in keyboard callback. Also it displays the "window:activate" and "focus:" events.
Created attachment 35949 [details] results of patch above This output is obtained by starting gnopernicus and pressing and releasing DEL key from numpad. As it can be seen "window:activate" events are present even if user doesn't change the current window. So, I still believe this is a dup of old bug #108664.
Remus: the problem here is that there is too much time spent in the keyboard callback. Remember, we said that in order to avoid the problems of bug #108664, the time spent in a callback (before returning 'TRUE' or 'FALSE' to the listener, for consuming a key) must be kept to a minimum. So, this means that gnopernicus needs to return from the callback before it has finished processing the flat review command. If that is the problem, then this _is_ a gnopernicus bug - or at least the problem can be avoided by gnopernicus.
Remus: I see that the elapsed times in your output are quite small - so gnopernicus isn't taking too long in this particular case. However, you don't indicate whether the Del key is (ever) repeating or not. If key repeat is used, then I think the "stray" events are unavoidable. But if this happens even when key repeat is on, the problem is more serious. Also in your test, the 'AAAA' events are not as common as were reported by the Evolution team - we need to figure out why that is to. So we still need more info in order to establish the cause and severity of this problem, and whether there are ways to avoid it.
To clarify:I think my conclusion in comment #7 was wrong, if the output timing is in seconds. Also I said, in comment #8: "But if this happens even when key repeat is on, the problem is more serious." I meant "when key repeat is OFF", of course.
Bill: all keyboard events are reported to srcore on an idle. See bug #138391. So, the time spent in the calback is minimum possible. I made (on my computer) a new test. The callback function does nothing except to start the timer, stop it and display the time. The results are same but the time is shorter (about 20 times shorter). "the 'AAAA' events are not as common as were reported by the Evolution team" -- this is because I have pressed the key and I have dold it for a while. If I press and release it quickly, the those events are more common.
When key repeat is OFF is even worse. In this case a "focus:" event is obtained in combination with "window:activate" event. I have pressed the key, hold it a while (about 1 or more second) and released it. _Always_ a pair of "window:activate", "focus:" events is obtained after release. But, if the key is not hold, the bug was _never_ reproduced.
OK, this makes sense. You should never hold the key down while in screen review mode, this will cause the code for bug 108664 to fail. Evolution team, can you confirm that this bug does NOT occur when the user does not hold the numpad-2 key down?
The right question is: Evolution team, can you confirm that this bug does NOT occur when the user does not hold the numpad-2 key down and key repeat is OFF?
To the question in #13: I've made the verification and the result is: this bug can still be reproduced when the user doesn't hold the numpad-2 key down and key repeat is OFF.
Created attachment 36181 [details] [review] proposed stand alone test The test simulate the gnopernicus behaviour for the numpad keys.
Tim, can you run the test above and post the log. The file must be copied in at-spi/test directory. On my computer, the unwanted window:activate is present when running test and gedit and pressing "Del" key (while in gedit) from numpad.
The unwanted event is present in same cases as I said at comment #11 and comment #6 when repeat is ON.
Transferring to at-spi for more investigations.
I am still unclear about the cases being reported here. Let's exclude the case where key repeat is ON, and talk only about key-repeat OFF. Please make sure that the user does not hold any key down, but releases each key soon after pressing it. In this case the unwanted events should not be emitted.
Bill, in case describe by you (repeat OFF, not holding) the behaviour is normal on my computer (see last sentence from commnet #11). But it is still present on Tim's computer (comment #14).
Not reproducible on our systems... is this bug visible with recent builds/recent XServers?
lowering severity and priority due to limited reproducibility across configurations.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.