GNOME Bugzilla – Bug 525650
Orca key strokes conflict with entering data in java applications
Last modified: 2008-06-17 15:02:01 UTC
Please describe the problem: There seems to be orca commands on standard typing keys when using a java application. This bug makes it difficult/impossible to enter certain characters from the keyboard. Steps to reproduce: 1. Load a java application (for this I will describe it using MathTrax) 2. tab to a text box (the equation entry box of MathTrax does) 3. Try entering = (equals sign) using the = key on the main part of the keyboard 4. Observe output Actual results: Orca speaks script and module information Expected results: An = (equals sign) would appear in the text box Does this happen every time? Seems to happen all the time, and I believe with other java applications. Other information: This case described here is just for = but other keys don't work and so need looking at as well. Sun JDK 6 update 5 is being used with java-access-bridge 1.22.0.
See also bug 318615.
I was unware of bug 318615, but I don't think the two are related as I believe things were OK with orca 2.20.3 (and certainly with orca 2.18.3 (obviously earlier versions of gnome as well)).
I forgot to mention that this bug shows itself in learn mode, pressing = in learn mode gives "Reports information on current script". I don't know if this will help track it down.
I have reproduced this problem with debugging on, it appears like orca is getting the right keycode, and it says that orca would echo = for key echo and I confirmed that is true by enabling key echo. I will generate a debug of the same in orca 2.20, take out the relevant information and make them available for comparison.
Created attachment 112680 [details] Debug file showing the problem when using orca 2.22. The actions performed to generate the debug file (with MathTrax open and focus on the equation entry box) are: start orca, tab once to instruction box, shift-tab back to equation entry box, press = key, use ctrl+alt+f2 to move to a text console so that output could be got without further messages from orca.
Created attachment 112681 [details] debug output for orca 2.20. This has been generated in the same way as attachment 112680 [details], but instead using orca 2.20.
Did you apply the patch from bug 318615 and then rebuild/reinstall the java-access-bridge? Without that, you're not going to see any differences. :-(
I have now applied the patch from bug 318615, and this seems to solve the problem. May be this bug is just a way that bug 318615 shows itself. I just wonder why orca in the 2.20 branch does not seem to suffer from this bug without the patch to the java access bridge. Should orca 2.22 be made to behave as orca 2.20 does until a better fix (such as a fix to bug 318615) enters an actual release version of the java access bridge? (In reply to comment #7) > Did you apply the patch from bug 318615 and then rebuild/reinstall the > java-access-bridge? Without that, you're not going to see any differences. > :-( >
(In reply to comment #8) > I have now applied the patch from bug 318615, and this seems to solve the > problem. May be this bug is just a way that bug 318615 shows itself. I just > wonder why orca in the 2.20 branch does not seem to suffer from this bug > without the patch to the java access bridge. I'm not sure. I've not been able to reproduce the successful behavior with 2.20, though. > Should orca 2.22 be made to behave > as orca 2.20 does until a better fix (such as a fix to bug 318615) enters an > actual release version of the java access bridge? We'll work to get the Java access bridge patch in for GNOME 2.22.3.
Blocking bug fixed. Closing this as FIXED.