GNOME Bugzilla – Bug 440238
Java text events have null text objects
Last modified: 2008-07-22 19:27:05 UTC
To avoid confusion, I'm opening a single bug to cover the numerous problems caused by Java text events having null text objects. I'm closing the other null text object bugs as duplicates of this one. The problem is that the Java Access Bridge for GNOME (JABG) receives and forwards good text events to the Registry. However, Orca receives text events with null text objects. I haven't determined whether this problem occurs for all types of text events, from all Java text components. However, the problem occurs, at least, for caret-moved events from JTextFields and JTextAreas.
Email from Lynn to Jeff Cai: Hi Jeff, I'm trying to fix a bug where Orca receives caret-moved events, but the text object in the Python events are null. As a test case, I created a simple Java application that displays a JTextField containing the string "This is a text field.". I added some trace statements to the dispatchEvent method in JavaBridge.java. The statement simply prints the contents of the caret moved event when it is received. I added similar statements to EventQueueRegistry.java printing the event contents just before the event is processed. Here's the output when I right-arrow in the JTextField: // from JavaBridge.dispatchEvent Caret EVENT : 9, 8 start = 9, end = 9 dispatching event with ANY type com.sun.corba.se.impl.corba.TypeCodeImpl@1462851 = null object:text-caret-moved 9,8 from javax.swing.JTextField$AccessibleJTextField@1bb60c3 dispatched text event text contents: This is a text field. // from EventQueueRegistry.processEvent processEvent: object:text-caret-moved processed text event text contents: This is a text field. It appears to me that the event is good when the event is sent to the registry. I'm guessing that something is going wrong in the Python CORBA implementation, but I need to be more sure about this. Any suggestions for tracing the problem further? Also, if you believe the problem is in the Python CORBA implementation, do you know whom I can contact to get this problem resolved? It's a big problem for Orca with Java text. Thanks! Lynn
*** Bug 435567 has been marked as a duplicate of this bug. ***
*** Bug 435565 has been marked as a duplicate of this bug. ***
Lynn, could you give me your java testing code so I can test it?
This might be fixed. See also bug 360272 and bug 435825.
Created attachment 88629 [details] Java test program that displays a frame containing an editable text field Jeff, Here's the Java test program. When you hit the button, it displays the current text extents as returned by the Java Accessibility API. You can compare them to what the JABG gets when it calls the AT-SPI method to get the extents. Lynn
*** Bug 407704 has been marked as a duplicate of this bug. ***
I installed the latest pyorbit and confirmed this bug is fixed by the fix for pyorbit bug 435825. Orca speaks each character as I right-arrow through the text field in the Java test program. In addition, the onCaretMoved method in J2SE_access_bridge.py shows that the event source text object is correct. Should this bug be closed as fixed, even though the pyorbit fix is not in the latest GNOME release?
> I installed the latest pyorbit and confirmed this bug is fixed by the fix for > pyorbit bug 435825. Orca speaks each character as I right-arrow through the > text field in the Java test program. In addition, the onCaretMoved method in > J2SE_access_bridge.py shows that the event source text object is correct. Yee haa!!! I have a feeling this will close a number of our Java-related bugs. > Should this bug be closed as fixed, even though the pyorbit fix is not in the > latest GNOME release? I think it is fair to mark is as FIXED with a target of 2.19.3, since http://bugzilla.gnome.org/show_bug.cgi?id=435825#c7 says it will "go into the next software release", which is GNOME 2.19.3.
I'll release PyORBit 2.14.3 next weekend, in sync with GNOME 2.18.2.
(In reply to comment #10) > I'll release PyORBit 2.14.3 next weekend, in sync with GNOME 2.18.2. > Thanks so much!
I'm closing this with the target 2.19.0, since that is the next target on the list after 2.18.0.