Apache OpenOffice (AOO) Bugzilla – Issue 74943
[a11y] Writer goes into error recovery mode when running with Orca.
Last modified: 2013-08-07 14:42:49 UTC
See also Orca bug #412252 for more details. http://bugzilla.gnome.org/show_bug.cgi?id=412252 On my Ubuntu Feisty system (with all the latest updates), OOo 2.2.0 (RC1) Writer will go into error recovery mode with the following two scenerios: Scenerio 1: 1. Launch Orca 2. Launch OOo Writer 2.2 3. Alt O for the Format menu 4. Down arrow to paragraph and press Enter 5. Move focus to the Borders page (the first time I control page down'ed to it; subsequent times it remembers that is where I last was) 6. Tab to the Style list, Down Arrow a few times, Up Arrow a few times 7. Escape to exit the dialog 8. Alt F4 to exit OOo Writer. Scenerio 2: 1. Launch Orca 2. Launch OOo Writer 2.2 3. Control O for the Open dialog 4. Tab to File Type 5. Use Alt Down Arrow to expand the list. Then Up/Down Arrow among the items. 6. Escape to collapse the list, Escape again to exit the Open dialog. 7. Alt F4 to exit OOo Writer This is testing with Orca is 2.17.92 and the latest version of at-spi (1.17.1)
A11y => 2.3
Why wasn't it already assigned to some developer ?!
->mt: What makes you think this issue is ready to be reassigned? Did you reproduce? Do you have any proof it still exits? Do you have a crash report? Reassigned back to QA
mt->es: os is right, better QA first confirms that it still exist in OOo 2.2. But - when receiving accessibility bugs, please don't wait 2 month for handling this in some way.
ES->OBR: please test this on Ubuntu. Not reproducible on Solaris Nevada 61.
Confirmed, even if it doesn't crash always for me. Here is the stack from the Ubuntu build: #0 0xb75b33ea in Container::First () from /usr/lib/openoffice/program/libtl680li.so #1 0xb7ebf0c9 in ?? () from /usr/lib/openoffice/program/libvcl680li.so #2 0xb7ebf219 in TabControl::GetTabPage () from /usr/lib/openoffice/program/libvcl680li.so #3 0xb7de4131 in ?? () from /usr/lib/openoffice/program/libvcl680li.so #4 0xb7de41d6 in ?? () from /usr/lib/openoffice/program/libvcl680li.so #5 0xb7de4346 in ?? () from /usr/lib/openoffice/program/libvcl680li.so #6 0xb7de451f in Window::GetLabeledBy () from /usr/lib/openoffice/program/libvcl680li.so #7 0xb70fc2e2 in VCLXAccessibleComponent::FillAccessibleRelationSet () from /usr/lib/openoffice/program/libtk680li.so #8 0xb70fee0e in VCLXAccessibleComponent::getAccessibleRelationSet () from /usr/lib/openoffice/program/libtk680li.so #9 0xb59fa004 in ?? () from /usr/lib/openoffice/program/libvclplug_gtk680li.so #10 0xb5660c09 in atk_object_ref_relation_set () from /usr/lib/libatk-1.0.so.0 #11 0xb528ba13 in ?? () from /usr/lib/libspi.so.0 #12 0x08a17dc0 in ?? () #13 0xb6f40bf0 in pthread_mutex_unlock () from /lib/tls/i686/cmov/libpthread.so.0 #14 0xb52883a7 in _ORBIT_skel_small_Accessibility_Accessible_getRelationSet () from /usr/lib/libspi.so.0 #15 0xb51c0767 in ?? () from /usr/lib/libORBit-2.so.0 #16 0x08a5d564 in ?? () #17 0xbfcd28a4 in ?? () #18 0x00000000 in ?? ()
pb: too late for 2.3 -> 2.4.
added myself to cc
MD: Adjusted priority and added keyword "crash".
pb: I set the target to 2.4 because I was not able to reproduce this crash with an Ubuntu VMware image. The stack which was created by Oliver (obr) is not very significant. So I gave other issues a higher priority. I will try to reproduce it again after the 2.3 is finished.
Ok, it seems we're getting closer (even though the crash seems still to be hard to reproduce): In Scenario 1 one gets the following output on the command line: (soffice:4691): GLib-GObject-CRITICAL **: file gobject.c: line 1478: assertion `G_IS_OBJECT (object)' failed I tracked this down to be caused by the class AccessibleFrameSelector neither exposing TRANSIENT state nor implementing XAccessibleEventBroadcaster, which IMO doesn't fit together. This caused an LABEL_FOR relation to have a target pointer of NULL. Maybe we can create some test script based on this assumptions/findings to further isolate the problem. However, I should probably modify the bridge code to handle this error more gracefully.
Looking at the Orca bug referenced above, it seems that Scenario 2 happens only with the Gtk-FilePicker implementation, which unfortunately crashes instantly on my snv 77 build. This means that scenario has probably a totally different root cause. BTW: one can switch between OOo and Gtk FilePicker under Tools - Options - OpenOffice.org - General - Use OpenOffice.org dialogs. Seems that the ubuntu build uses a different default for this option.
Restored blocker issue deleted by accident.
I have committed the workaround for the GLib-GObject-CRITICAL warning in CWS fwk83 and submitted issue 85353 for the real fix. I have also submitted an RFE for the UNO based AccessibilityWorkbench tool (issue 85354) to make catching such mismatches easier. Is Scenario 2 also considered a stopper for 2.4 (given that it is related to the gtk file picker dialog, which is disabled by default in vanilla OOo) ?
pb: Oliver,thank you for your work. Because there is a workaround (use the office file picker) I think scenario 2 is not a showstopper any longer. So I set this task to "Fixed".
pb -> es: please verify in cws fwk83. Thx.
Well due to the fact that: 1) I can reproduce neither Scenario 1 nor 2 (Solaris Nevada) in the master. 2) I am able to reproduce "a" crash which corresponds "more or less" to the both scenari, both in the master AND this CWS: - start soffice - new Writer - File - Open (OOo dialog!) - Cancel dialog - Ctrl+W to close the Writer - Ctrl+Q to quit OOo -> OOo terminates with a core dumped. 3) quite nobody could reproduce the scenarii. What should I test where when? I can't see any fix here. Please explain.
@OBR: Sorry but I can't either reproduce my scenario 3 (in the CWS) nor the error*** mentioned on schenario 1 (in the master). ***(soffice:4691): GLib-GObject-CRITICAL **: file gobject.c: line 1478: assertion `G_IS_OBJECT (object)' failed still don't know what to verify.
grrr.... to many things at a time... "with Orca" is pretty important! Sorry! :((( Verified in CWS fwk83
.
Verified with Orca on Gnome/Ubuntu/OOo 3.0, I've tried the different scenarios and could not reproduce any crash. So closing - Sophie