GNOME Bugzilla – Bug 435585
Java ControlPanel GIVING UP AFTER 5 TRIES Advanced Settings tree table
Last modified: 2008-06-10 18:18:04 UTC
Orca cannot speak the Java ControlPanel Advanced Settings tree table items because of repeated communication failures. Selecting an item in the tree table always results in Orca giving up handling the focus event because of COMM_FAILURES. The Corba failures are all of the type org.omg.CORBA.UNKNOWN: vmcid: SUN minor code: 202 completed: Maybe which indicates that a Corba communications retry occurred. According to the Sun Corba team, these are warning messages, and can be safely ignored. These retries frequently occur when I test Java applications with Orca. However, it's rare when the Orca event handling times out after 5 retries. When navigating this tree table, the retries always time out.
My results may be an anomaly in that I frequently get COMM_FAILURE retries when running Java applications with Orca. However, the Baum team told me that they rarely saw these retries when they were working on J2SE-access-bridge.py. This issue needs more investingation: 1. Why is Corba still emitting these warning messages? The problem was supposed to be fixed in Java 6. 2. Are the retries really a bug, instead of a normal occurrence, like the Corba team state? 2. Why are the retries failing for this tree table? 4. Is there some run-time environmental setting that is causing some people (like me) to get a lot of these retries? In particular, more people need to run the Java ControlPanel with Orca to see if they get the same COMM_FAILURE's.
> In particular, more people need to run the Java ControlPanel with Orca to see > if they get the same COMM_FAILURE's. I did get a bunch of COMM_FAILURE's and I couldn't access the tree table.
It looks like this is a general, and more serious problem. I cannot recall any components that were inaccessible because the requests always timed out.
Created attachment 91876 [details] blocking bug description This bug is blocked by http://bt2ws.central.sun.com/CrPrint?id=6553303 Jeff Cai changed the blocking bug priority Priority changed from [2-High] to [1-Very High] Accesibility can't work on nevada unless this bug is fixed. jeff.cai@sun.com 2007-06-21 05:28:47 GMT
Added blocking bug.
A fix is available for the blocking bug http://bt2ws.central.sun.com/CrPrint?id=6553303. The fix is scheduled to be available in Java 5, update 14.
CR 6553303 was marked as FIXED. It wasn't. Jeff opened a new bug: *Synopsis*: Java accessibility clients can't communicate with corba server sometimes http://bt2ws.central.sun.com/CrPrint?id=6627380
See also bug 531869 and bug 527128.
Created attachment 111967 [details] [review] Patch to process Java events synchronously This patch adds a new setting, synchronousToolkits, which is a list of the names of toolkits that must be processed synchronously. Seems to work well with when used in conjunction with bug #531869. The main concern about this patch is that it introduces an immediate round trip to get the toolkit name associated with the application for every event. I need to run a profile of the regression tests to see what the true impact is -- the "cProfile" package seems to be gone on my Solaris box, though, so I need to find it first.
Patch committed. We all agree this is a nasty hack to work around the real issue, but the real issue has remained a nasty undiscoverable thing for several years. In addition, with the AT-SPI/DBus work on-going, this is really serving as a stop-gap to get Java working better until that work is done. When that work is done, we can pull this hack out. Performance testing seems to indicate this doesn't introduce significant performance issues. However, I'm still concerned that it might. The biggest impact might be when new windows open and flood us with events, causing sluggishness with Orca's initial presentation of new window content. Marking this as [pending].
Patch also committed to the gnome-2-22 branch for GNOME 2.22.3.
Closing as FIXED.