GNOME Bugzilla – Bug 436664
[blocked] Cannot flat-review Java text
Last modified: 2008-07-22 19:27:47 UTC
It is not possible to flat-review the contents for the SwingSet2 JEditorPane demo. 1. Start the SwingSet2 demo 2. Navigate to the JEditorPane demo. 3. Use the up and down arrow keys to speak the links in the JEditorPane ("Title page", "To the King, etc.) 4. Hit KP_8 to enable flat-review and speak the current line in the JEditorPane. Note that Orca does not speak the current line. Instead, it speaks the SwingSet2 toolbar. 4. Hit KP-9 to navigate to the JEditorPane contents. Note that it is not possible to flat-review the contents. Flat-review jumps from the toolbar to the scrollbar thumbs.
I tested flat-review in the JTextArea in the JProgressBar demo. It was not possible to flat-review the JTextArea either. This indicates a more general problem flat-reviewing Swing text. 1. Launch SwingSet2 2. Launch the JProgressBar demo and hit the "Start Loading Text" button. The demo will enter text into the JTextArea above. Hit the "Stop Loading Text" button after a few lines of text have been entered. 3. Without using flat-review, navigate to the JTextArea and arrow through the text. Orca will speak each line correctly. 4. Use flat-review to try and do the same thing. You cannot.
This appears to be a general problem with flat-reviewing Java text. I wrote a small Java test program that displays a JTextField containing "This is a line of text." The flat_review.splitTextIntoZones method calls text.getRangeExtents, which returns zero for x, y, width and height for all Java text lines that I tested. I checked whether the JABW is sending the correct extents. It appears that the JABW is forwarding text events with the same incorrect extents, zero x, y, widht and height values. Here's the output of trace statements in the JavaBridge.dispatchEvent method when I move the cursor in the Java text program JTextField. The 'textfield rect' is the bounding rectangle as returned by Java Accessibility API method getAccessibleComponent().getBounds(), which appears to be correct. 'text range extents' is the output of the AT-SPI method 'getRangeExtents' which is clearly wrong. Caret EVENT : 8, 7 start = 8, end = 8 dispatching event with ANY type com.sun.corba.se.impl.corba.TypeCodeImpl@ef137d = null object:text-caret-moved 8,7 from javax.swing.JTextField$AccessibleJTextField@18f5824 text string: This is a text line. textfield rect: java.awt.Rectangle[x=155,y=8,width=106,height=19] text range extents: 0 0 0 0 So, it appears that the AT-SPI method getRangeExtents is returning wrong values, which is causing Orca flat-review code to believe the text is not showing, and so, doesn't flat review it.
Yikes! This is bad! Please investigate and file a bug with the appropriate component (Java access bridge?).
Created attachment 88689 [details] Java test program that displays a frame containing an editable text field I'm reassigning this bug to the Java Access Bridge for GNOME. This comment is directed to Jeff Cai. The easiest way to reproduce the problem is to modify the JavaBridge.dispatchEvent method to get and print text extents using the AT-SPI text method 'getRangeExtents'. Run the TextArea application that I've attached and just click on the textfield contents.
> I'm reassigning this bug to the Java Access Bridge for GNOME. Please make sure we keep a tracking bug open in Orca for this. Mark the tracking bug as [blocked] and make sure the tracking bug in Orca is marked as depending upon the JABG bug. It will help us keep track of things that we need to keep track of.
> Please make sure we keep a tracking bug open in Orca for this. Mark the > tracking bug as [blocked] and make sure the tracking bug in Orca is marked as > depending upon the JABG bug. It will help us keep track of things that we need > to keep track of. Ah! You did it. Thanks!
Removing target milestone from [blocked] bugs. We have little control over them, so we're better off letting priority and severity be our guide for poking the related components.
I reproduced this problem attempting to flat-review the HTML text in the Sun Download Manager help dialog.
I'll take a look at this bug soon.
The problem here is that the getRangeExtents method in impl/org/CORBA/Accessibility/TextImpl.java is not implemented, so the x, y, width and height IntHolder values are always zero. public void getRangeExtents (int startOffset, int endOffset, org.omg.CORBA.IntHolder x, org.omg.CORBA.IntHolder y, org.omg.CORBA.IntHolder width, org.omg.CORBA.IntHolder height, short coordType) { } I'll propose an implementation.
Created attachment 89981 [details] partial implementation for getRangeExtents For testing purposes, this is partial implementation for the getRangeExtents method in the JABG. It doesn't handle the case where the coordType is 1. This is easy to do reusing the ComponentImpl.getPosition code. The private getTopLevelLocationOnScreen method needs to be shared. However, the getRangeExtents call in splitTextIntoZones still gets [0, 0, 0, 0]. I don't know why this is happening since the System.err.println statements in getRangeExtents indicate the correct [x, y, width, hight] values are being returned.
Lynn, I tested SwingSet with your patch. But it seems can't read the current line.
> However, the getRangeExtents call in splitTextIntoZones still gets [0, 0, 0, > 0]. I don't know why this is happening since the System.err.println statements > in getRangeExtents indicate the correct [x, y, width, hight] values are being > returned. Java doesn't pass method arguments by reference; it passes them by value. So, the way the patch is written won't work as you might expect. :-( I think what you might need to do is something like: x.value = rect.x y.value = rect.y width.value = rect.width height.value = rect.height See also: http://java.sun.com/j2se/1.4.2/docs/api/org/omg/CORBA/IntHolder.html
You are right about needing to explicitly setting IntHolder.value. I've attached getRangeExtents that works for Orca flat-review. However, I'm confused by the the existing JABG methods that have IntHolder methods. Many JAWG methods use 'new IntHolder' to return values. For example, here is the getPosition method in impl/org/CORBA/Accessibility/ComponentImpl.java that I used as a guide for implementing getRangeExtents. public void getPosition (org.omg.CORBA.IntHolder x, org.omg.CORBA.IntHolder y, short coord_type) { if (accComponent != null ) { Point p = accComponent.getLocationOnScreen(); if (coord_type != 0) { Point toplevelp = getToplevelLocationOnScreen(); p.x -= toplevelp.x; p.y -= toplevelp.y; } x = new org.omg.CORBA.IntHolder(p.x); y = new org.omg.CORBA.IntHolder(p.y); } } Do we have a bunch of broken JABG methods? I need to check.
Created attachment 90025 [details] implementaion that works for Orca text flat-review Should we post a patch on the JABG page in our wiki?
> I'm > confused by the the existing JABG methods that have IntHolder methods. Many > JAWG methods use 'new IntHolder' to return values. For example, here is the > getPosition method in impl/org/CORBA/Accessibility/ComponentImpl.java that I > used as a guide for implementing getRangeExtents. ... > public void getPosition (org.omg.CORBA.IntHolder x, > org.omg.CORBA.IntHolder y, short coord_type) { ... > x = new org.omg.CORBA.IntHolder(p.x); > y = new org.omg.CORBA.IntHolder(p.y); ... > Do we have a bunch of broken JABG methods? I need to check. Nice catch! It certainly looks like things might broken elsewhere. Bummer! But, it may not be so bad: wwalker@wwalker-laptop:~/java-access-bridge/trunk/impl/org/GNOME/Accessibility$ grep "new org.omg.CORBA" *.java ComponentImpl.java: x = new org.omg.CORBA.IntHolder(p.x); ComponentImpl.java: y = new org.omg.CORBA.IntHolder(p.y); ComponentImpl.java: width = new org.omg.CORBA.IntHolder(d.width); ComponentImpl.java: height = new org.omg.CORBA.IntHolder(d.height); These appear in the getPosition and getSize methods.
(In reply to comment #15) > Created an attachment (id=90025) [edit] > implementaion that works for Orca text flat-review Yeah! Nice catch and nice fix. > Should we post a patch on the JABG page in our wiki? I'm thinking just getting it into SVN should be good so it will go out with GNOME 2.19.{4|5} and definitely GNOME 2.20, but I'm open to ideas. Where on the JABG page do you think it might live?
I don't think there's a need to provide a patch, if a fix can be provided in a GNOME release that's coming out soon. I'll file a bug against the JABG and recommend my fix. I'll also submit a JABG bug report requesting the getSize and getPosition problems be fixed.
Nice work, Lynn. You can post your patch in bugzilla and if the patch is okey then you can commit it to upstream.
The propose patch for Bug 440775 was integrated by Jeff Cai. Thanks! 2007-06-19 Jeff Cai<jeff.cai@sun.com> * configure.in: Version 1.19.1 * impl/org/GNOME/Accessibility/ComponentImpl.java: (ComponentImpl.getPosition), (ComponentImpl.getSize): Fix #448007, set correct paramter values of getPosition and getSize * impl/org/GNOME/Accessibility/TextImpl.java: (TextImpl), (TextImpl.getRangeExtents): Fix #448001, add implementation of getRangeExtents