Bugzilla – Bug 534100
Table cells don't have ChildOf relations to parents
Last modified: 2009-10-16 15:47:47 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.
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).
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. =================================================================
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.
Fixed in r142334 (trunk), r142341 (1.0 branch).
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.
(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.