Created attachment 74184 [details]
python script to reproduce bug

This is a python script to reproduce the bug with the J2SE 1.5.0 Notepad demo application

added blocked keyword to synopsis

Removed bogus blocked keyword.

Hi Padraig,

Would you take a look at this bug.  Thanks!

Lynn

Add CC to gnome-a11y-bugs-ext@sun.com

Harry,

Do I understand correctly that you are the right person to discuss this bug with?

Lynn

jeff.cai@sun.com will take a look at this bug. Please discuss with him.

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 120705

Jeff, Thanks for the information. Do you know who I can contact about the Python binding?

(In reply to comment #9)
> Jeff, Thanks for the information. Do you know who I can contact about the
> Python binding?
> 

The Python bindings are automatically generated via PyORBit.  I'm not convinced that's the source of the problem, though.  Instead, there might be some bad assumption made on the part of the CORBA support in the Java platform and the PyORBit stuff is exposing it.

It may also be something Orca is doing, but I'm not sure.  Perhaps writing a test using the new pyatspi bindings might give us more information: http://live.gnome.org/GAP/PythonATSPI

> The Python bindings are automatically generated via PyORBit.  I'm not convinced
> that's the source of the problem, though.  Instead, there might be some bad
> assumption made on the part of the CORBA support in the Java platform and the
> PyORBit stuff is exposing it.

I take that back: see bug 435825.

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

I attached a test program to bug Bug 350742 that can be used to reproduce the problem. The test application create five labeled text fields. You can tab though the text fields and hear that Orca does not speak every text field, and that the text fields spoken are not the same when the test application is repeatedly run.

I still think this maybe a problem of pyorbit. Assign this bug to pyorbit and hope the maintainer could give us feedback soon.

There's not much I can discover about the problem.  The pyorbit wrapper for _narrow () looks fine to me.  There's only one C line that may be raising a CORBA exception:

    type_matches = CORBA_Object_is_a(self->objref, repo_id, &ev);

If this line raises COMM_FAILURE then there must be something wrong with the CORBA connection (perhaps the CORBA server crashed?), or there is a bug in ORBit2.

If I were you I'd start by running the python client with ORBIT2_DEBUG=all, assuming you have an ORBit2 built with --enable-debug.

I don't know much about orbit. Who can help us to see this issue? How about orbit guys?

Should talk to Michael Meeks <michael.meeks@novell.com>

Sure - so; given that you understand that the python object introspection & construction is done using a non-standard ORBit2 specific extension ;-) and that you've overcome that problem (somehow).

Then perhaps this is some interesting protocol problem.

Luckily there are a lot of ways to debug that. Firstly, configure ORBit2 with --enable-debug=yes, make clean ; make install # etc.

then cf. corba-orb.c:

#ifdef G_ENABLE_DEBUG
static void
ORBit_setup_debug_flags (void)
{
	static GDebugKey debug_keys[] = {
		{ "traces",         ORBIT_DEBUG_TRACES },
		{ "inproc_traces",  ORBIT_DEBUG_INPROC_TRACES },
		{ "timings",        ORBIT_DEBUG_TIMINGS },
		{ "types",          ORBIT_DEBUG_TYPES },
		{ "messages",       ORBIT_DEBUG_MESSAGES },
		{ "errors",         ORBIT_DEBUG_ERRORS },
		{ "objects",        ORBIT_DEBUG_OBJECTS },
		{ "giop",           ORBIT_DEBUG_GIOP },
		{ "refs",           ORBIT_DEBUG_REFS },
		{ "force_threaded", ORBIT_DEBUG_FORCE_THREADED }
	};
	const char *env_string;

	env_string = g_getenv ("ORBIT2_DEBUG");

I would start with (eg.) ORBIT2_DEBUG=traces - and if that doesn't show you what is going on, I'd extend it to "messages", "giop", "all" by the time you get to "giop" you'll need some protocol understanding.

Michael, i'm confused that if I use c interface to access corba, this error will not happen. Does this mean the problem exists in the implementation of pyorbit? 

Jeff - no idea :-) Almost certainly the python version is using dynamic introspection, where the C version is using static type information :-)

However - it's great to have a working & non-working version. That means you can get the debug output for both, and then compare them to isolate the difference easily.

Michael,

Do you have any news on this bug? It's a big accessibility problem since it's frequently impossible to get Java text field contents.

Thanks!

PyOrbit is not under active development anymore.

This project has been recently archived in GNOME Git.

It is currently unlikely that there will be any further active development.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again.