Bug 534100

Summary:	Table cells don't have ChildOf relations to parents
Product:	[Mono] UI Automation	Reporter:	Andres Aragoneses <aaragoneses>
Component:	Winforms - ATK	Assignee:	E-mail List <mono-a11y-bugs>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <mono-a11y-qa>
Severity:	Normal
Priority:	P2 - High
Version:	Unspecified
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	Patch

Description Andres Aragoneses 2009-08-25 15:29:06 UTC

Steps to reproduce:
1. Run gtk/gtktreeview.py sample.
2. Run accerciser, locate the "parent 0" item: it has a relation "child of" to the tree-table role element.
3. Locate the "child 0 of parent 0" item: it has a relation "child of" to the "parent 0" element.
4. Run winforms/treeview.py sample.

Current results:
No child-of relations.

Expected results:
Parent1 child-of the tree-table element, Child1 child-of Parent1, etc.

Comment 1 Andres Aragoneses 2009-08-25 16:40:16 UTC

Created attachment 315116 [details]
Patch

This fixes the issue (at least I've checked that with accerciser, but I haven't done a regression test yet).

Comment 2 Andres Aragoneses 2009-08-25 16:51:05 UTC

Mmm, and with the patch above am getting a SEGFAULT on at-spi (that is, without the patch it doesn't happen) if I close the treeview while inspecting it with accerciser:


Native stacktrace:

	/home/knocte/opt/mono/bin/mono [0x80c95a9]
	/home/knocte/opt/mono/bin/mono [0x805d6f8]
	[0xffffe410]
	/usr/lib/libORBit-2.so.0(giop_thread_request_push+0x88) [0xb52f6708]
	/usr/lib/libORBit-2.so.0 [0xb53104bb]
	/usr/lib/libORBit-2.so.0(ORBit_handle_request+0x52) [0xb5312502]
	/usr/lib/libORBit-2.so.0(giop_connection_handle_input+0x3a5) [0xb52fa8a5]
	/usr/lib/libORBit-2.so.0 [0xb5319c03]
	/usr/lib/libORBit-2.so.0 [0xb531c396]
	/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1e9) [0xb7e5c2f9]
	/usr/lib/libglib-2.0.so.0 [0xb7e5f87b]
	/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1ca) [0xb7e5fd4a]
	/usr/lib/libORBit-2.so.0 [0xb5317e00]
	/usr/lib/libglib-2.0.so.0 [0xb7e863bf]
	/lib/libpthread.so.0 [0xb7dd9175]
	/lib/libc.so.6(clone+0x5e) [0xb7d37dae]

Debug info from gdb:

[Thread debugging using libthread_db enabled]
[New Thread 0xb7c686f0 (LWP 11907)]
[New Thread 0xb4effb90 (LWP 11933)]
0xffffe430 in __kernel_vsyscall ()
  2 Thread 0xb4effb90 (LWP 11933)  0xffffe430 in __kernel_vsyscall ()
  1 Thread 0xb7c686f0 (LWP 11907)  0xffffe430 in __kernel_vsyscall ()

Thread 2 (Thread 0xb4effb90 (LWP 11933)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb7ddfbab in read () from /lib/libpthread.so.0
#2  0x080c9723 in mono_handle_native_sigsegv (signal=11, ctx=0xb4efedcc)
    at mini-exceptions.c:1565
#3  0x0805d6f8 in sigsegv_signal_handler (_dummy=11, info=0xb4efed4c, 
    context=0xb4efedcc) at mini.c:4259
#4  <signal handler called>
#5  0xb7e5a0f2 in g_list_append () from /usr/lib/libglib-2.0.so.0
#6  0xb52f6708 in giop_thread_request_push () from /usr/lib/libORBit-2.so.0
#7  0xb53104bb in ?? () from /usr/lib/libORBit-2.so.0
#8  0xb5312502 in ORBit_handle_request () from /usr/lib/libORBit-2.so.0
#9  0xb52fa8a5 in giop_connection_handle_input () from /usr/lib/libORBit-2.so.0
#10 0xb5319c03 in ?? () from /usr/lib/libORBit-2.so.0
#11 0xb531c396 in ?? () from /usr/lib/libORBit-2.so.0
#12 0xb7e5c2f9 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#13 0xb7e5f87b in ?? () from /usr/lib/libglib-2.0.so.0
#14 0xb7e5fd4a in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#15 0xb5317e00 in ?? () from /usr/lib/libORBit-2.so.0
#16 0xb7e863bf in ?? () from /usr/lib/libglib-2.0.so.0
#17 0xb7dd9175 in start_thread () from /lib/libpthread.so.0
#18 0xb7d37dae in clone () from /lib/libc.so.6

Thread 1 (Thread 0xb7c686f0 (LWP 11907)):
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb7ddf7a9 in __lll_lock_wait () from /lib/libpthread.so.0
#2  0xb7ddac66 in _L_lock_89 () from /lib/libpthread.so.0
#3  0xb7dda572 in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0xb5310dd4 in PortableServer_POA_destroy () from /usr/lib/libORBit-2.so.0
#5  0xb52fb356 in CORBA_ORB_shutdown () from /usr/lib/libORBit-2.so.0
#6  0xb52fb4cf in CORBA_ORB_destroy () from /usr/lib/libORBit-2.so.0
#7  0xb52fcc5f in ?? () from /usr/lib/libORBit-2.so.0
#8  0xb7c978f1 in exit () from /lib/libc.so.6
#9  0xb7c805fd in __libc_start_main () from /lib/libc.so.6
#10 0x0805ad31 in _start ()
#0  0xffffe430 in __kernel_vsyscall ()

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Comment 3 Andres Aragoneses 2009-08-25 17:45:14 UTC

Raising severity because this is clearly a problem with Orca.

Steps to reproduce:
1. Open ORCA, open winforms/treeview.py.
2. Locate yourself in Parent1: orca says "collapsed".
3. Click right arrow.

Current results:
Orca says "0 children"

Expected results:
Orca should say the correct number of children.

Comment 4 Andres Aragoneses 2009-09-21 17:50:22 UTC

Fixed in r142334 (trunk), r142341 (1.0 branch).

Comment 5 Andres Aragoneses 2009-09-22 21:36:30 UTC

Somehow this is a DUPE of a bug with bigger scope (because it affected to more kinds of widgets): bug 479142:

http://lists.ximian.com/pipermail/mono-patches/2009-March/143543.html

I'll have to check if I need to refactor the solution then, to really fix the code that regressed in that commit of mario.

Comment 6 Andres Aragoneses 2009-10-16 15:47:47 UTC

(In reply to comment #5)
> I'll have to check if I need to refactor the solution then, to really fix the
> code that regressed in that commit of mario.

Fixed properly in r144274,144275.