[SPAM] Thankyou for your bug report. Adding a comment 
here to get it off the "Bugs awaiting a response" list.

Please state which java applications and textboxes (sometimes) have this problem.  Thanks!

For example, TableExample application.
When the application starts, there are 4 textboxes. Sometimes, orca doesn't report the content of some of the textboxes, it only reports "text".

This problem frequently occurs for JTextFields, but not other Swing text objects like JTextAreas. COMM_FAILUREs frequenly occur narrowing the text object to Accessibility.text. Submitted bug 360272 against the gnome-access-bridge.

This comment comes from bug 360272.
I used demo/jfc/TableExample as my target instead of Notepad because JavaBridge
has a bug that "string out of index". This is another problem so I put it
aside.

TableExample has a dialog "Connection Information" which contains four
JTextField widgets. When you switch among them, the python script you give me
will report "COMM_FAILURE" in one of them. But for other three ones, it is ok.

I change the code of simple-at, a test program in c code, to make it work just
like the python script, the test result is ok.

python output:

notifyEvent focus: 0 0
source:  <CORBA.Object '(null)' at 0x822a878>
name=None role='text' state='EDITABLE ENABLED FOCUSABLE FOCUSED OPAQUE
SENSITIVE SHOWING SINGLE_LINE VISIBLE'
text= <CORBA.Object '(null)' at 0x80d3810>
Traceback (most recent call last):

+ Trace 121341

who could help me to see python binding code or give me some clues?

Please also see bug 440238 - might be related.

Lynn, did the fix for bug 440238 also fix this one?

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.

Surprisingly, no. The problem reported here is that text is sometimes not spoken when there is more than one text field. I've attached a Java test application that displays five pairs of JLabels and editable JTextFields. I ran the following test about a dozen times:

1. Tab though the text fields and type text into each text field. I varied the text I entered, but it was usually something like "one", "two", "three", "four", "five".

2. Tab through the text fields, listening to what orca speaks. 

3. Tab through the text fields and arrow through the text.

The results were not always the same, except that there was always, at least one text field that was not spoken. More often, every other text field was not spoken. When I arrowed through the text in those text fields, the characters were not spoken. Trace statements in J2SE_access_bridge.onCaretMoved showed the text object in the event source was null.

Testing with the Sun Download Manager gave consistent results. Some text fields on a tabbed pane were always spoken and some were never spoken. For example, on the Sun Download Manager proxy setup page, the address field is never spoken, but the port number field is always spoken. The Java test program shows this is not an application-specific problem.

The problem fixed for Bug 435825 may be related in some way, but it's not obvious to me since this is an intermittent failure.

Darn.  I wonder if something is failing in atspi.py:__get_text and we end up
caching some nonesense value somehow.  It might be worth a try to debug that
area of the code to see what is going on when you tab around the test app.

The problem is that sometimes queryInterface("IDL:Accessibility/Text:1.0") or _narrow(Accessibility.Text) fails in __get_text__. I added a retry loop to see whether retrying the operation would succeed if it was retried. It never succeeds on a retry (even after 5 attempts). It appears the intermittent problem needs to be fixed in the JABG.

If it is the problem of JABG, queryInterface in C will also fail. retrying can't make sense, I think.

Created attachment 90287 [details]
test application for debugging

*** Bug 460709 has been marked as a duplicate of this bug. ***

For more information, when running with the latest java-access-bridge, latest at-spi, and latest Orca, I see the following errors appear on the java side:

Nov 1, 2007 10:10:56 AM com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl convertThrowableToSystemException
WARNING: "IOP00010202: (UNKNOWN) Unknown user exception thrown by the server"
org.omg.CORBA.UNKNOWN:   vmcid: SUN  minor code: 202 completed: Maybe
        at com.sun.corba.se.impl.logging.ORBUtilSystemException.runtimeexception(ORBUtilSystemException.java:8365)
        at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.convertThrowableToSystemException(CorbaMessageMediatorImpl.java:1918)
        at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1868)
        at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleThrowableDuringServerDispatch(CorbaMessageMediatorImpl.java:1821)
        at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:258)
        at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1680)
        at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1540)
        at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:922)
        at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:181)
        at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:694)
        at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:451)
        at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1187)
        at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:417)
Caused by: java.lang.NullPointerException
        at org.GNOME.Accessibility.AttributeSetHelper.write(AttributeSetHelper.java:92)
        at org.GNOME.Accessibility.AccessiblePOA._invoke(AccessiblePOA.java:330)
        at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:637)
        at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:189)
        ... 8 more


and the following errors on the Orca side:

Traceback (most recent call last):

+ Trace 174362

Why flat review is in there is beyond me, except perhaps if it's due to a keycode mismatch with Java.  The mismatch might be causing a key to be inadvertently treated like a flat review command.

Oops...need to add this:

bash-3.2$ $JAVA_HOME/bin/java -version
java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)
bash-3.2$ uname -a
SunOS solaris-devx 5.11 snv_76 i86pc i386 i86pc Solaris

See also Bug 435585, which might point to the source of this problem.

(In reply to comment #18)
> See also Bug 435585, which might point to the source of this problem.

The patches associated with bug 435585 seem to fix this issue.

Tested with patches associated with bug #435585.  It now works.  Closing as FIXED.