GNOME Bugzilla – Bug 356066
Items in OOo's Navigator window are not always spoken
Last modified: 2009-05-02 03:22:42 UTC
Please describe the problem: The first time you get into Openoffice.org's Navigator window, Orca provides access to the tree items as you arrow around. If you then Escape out of the Navigator and return to it, Orca does not provide access to those tree items. The work-around is to move focus out of the tree and back to it. Steps to reproduce: 1. Launch Orca 2. Launch Openoffice.org writer 3. Press F5 for the Navigator window 4. Press Alt F6 to give the Navigator window focus 5. Arrow around the tree items. 6. Press Escape to close the Navigator window 7. Repeat steps 3 through 5 8. Press Tab followed by Shift Tab to move focus out of and then back to the tree 9. Repeat step 5. Actual results: The first time you perform step 5, the tree items are announced as expected. The second time you perform step 5, the tree items are not announced. The third time you perform step 5, the tree items are announced. Expected results: The tree items would always be announced. Does this happen every time? Yes* Other information: *I can reliably reproduce this on two machines on which I've installed OOo 2.0.4 RC available from openoffice.org. I CANNOT reproduce this in the version of OOo 2.0.3 that is installed along with Ubuntu Edgy Eft. I am running the latest Edgy on all three machines and Orca from CVS HEAD.
Tracking.
Add accessibility keyword. Apologies for spam.
Created attachment 75253 [details] debug.out from run that reproduces problem I noticed a stack trace in here: Traceback (most recent call last):
+ Trace 77895
s.processObjectEvent(event)
self.listeners[key](event)
self.onFocus(event)
orca.setLocusOfFocus(event, newFocus)
orca_state.locusOfFocus)
newLocusOfFocus)
if oldLocusOfFocus.role == rolenames.ROLE_MENU_ITEM and \
I unfortunately can't reproduce this with OOo v2.0.4 and latest Orca from CVS HEAD on my Solaris box. No Tracebacks. I went to try to install OOo v2.0.4 on my Ubuntu Edgy Eft system and got: % cd ~/OOD680_m4_native_packed-1_en-US.9070/RPMS % sudo rpm -Uvih *.rpm error: Failed dependencies: /bin/sh is needed by openoffice.org-core10-2.0.4-4.i586 libgnomevfs-2.so.0 is needed by openoffice.org-gnome-integration-2.0.4-4.i586 libgconf-2.so.4 is needed by openoffice.org-gnome-integration-2.0.4-4.i586 I have all the latest Ubuntu updates. What am I missing?
OOo v2.0.4 now installed. The traceback I see when testing this is: Traceback (most recent call last):
+ Trace 79035
orca.setLocusOfFocus(event, child)
oldLocusOfFocus, newLocusOfFocus)
self.updateBraille(newLocusOfFocus)
line.addRegions(self.brailleGenerator.getBrailleContext(obj))
result = self.getBrailleRegions(parent, False)
result = generator(obj)
return [regions, regions[focusedRegionIndex]]
Investigating...
Created attachment 75538 [details] [review] Patch to fix the "Index out of range" problem. The attached patch fixes the Traceback when you Tab to the combo box at the bottom of the Navigator window. Still getting the no speech for the Navigator tree though. at-poke shows that the contents are all labels. Now need to investigate if speechgenerator._getSpeechForTree() might have a problem with that.
Okay, I've looked at the initial debug.out attachment. We get speech when navigating the items in that tree table, because we are getting "object:selection-changed" events: vvvvv PROCESS OBJECT EVENT object:selection-changed vvvvv OBJECT EVENT: object:selection-changed detail=(0,0) ---------> QUEUEING EVENT object:active-descendant-changed app.name='soffice.bin' name=None role='tree' state='ENABLED FOCUSABLE FOCUSED SENSITIVE SHOWING VISIBLE MANAGES_DESCENDANTS' relations='' Sometimes when the Navigator window is displayed and we then arrow up and down in it, we do *NOT* get those events, and therefore can't speak them. Looks like yet another OOo bug. I'll try to create a standalone Python at-spi (look-no-Orca-code) script that reproduces the problem, and file another OOo bug against it, and block this one. Will, does my patch to braillegenerator.py look reasonable to check in?
Patch looks fine to me. Thanks!
Patch applied to CVS HEAD.
I've opened OOo issue #70966 http://www.openoffice.org/issues/show_bug.cgi?id=70966 against this problem, and adjusted the summary of this bug to reflect that we are currently blocked.
This may be related to a change in the bridge atk-bridge, but I'm not 100% sure. Here's some discussion on the topic that I wrote up in a private e-mail with Joanie after she did some preliminary investigation: "The diff (which I saw before, but thought it was benign...sorry) tells me that the at-spi bridge is now freeing the any_data field of an event immediately after the event is emitted, probably to eliminate a memory leak. This exposed a problem in Orca. In Orca, we add events to a queue and process them later. With this new change, any remote reference held in the any_data field is no longer valid after our callback is called. Thus...when we do something like the following in default.py, we're looking at an invalid object: wwalker@ubuntu:~/orca/trunk/src/orca$ find . -name \*.py | xargs grep -n any_data | grep makeAccessible ./default.py:2290: child = atspi.Accessible.makeAccessible(event.any_data.value()) And, we get this error: vvvvv PROCESS OBJECT EVENT object:active-descendant-changed vvvvv OBJECT EVENT: object:active-descendant-changed detail=(10,0) app.name='acroread' name=None role='tree table' state='ENABLED FOCUSABLE FOCUSED SENSITIVE SHOWING VISIBLE MANAGES_DESCENDANTS' relations='' Traceback (most recent call last):
+ Trace 101337
self.accessible.ref() OBJECT_NOT_EXIST
event type is and create/reference the accessible there. We probably should just do something like the following after we get the any_data (i.e., just before the 'else' on line 111): if e.type == "object:active-descendant-changed": e.any_data = Accessible.makeAccessible(e.any_data.value()) 3) In default.py:onActiveDescendantChanged around line 2290, use e.any_data directly: child = event.any_data This might work. In addition, the "object:text-changed:insert" and "object:text-changed:delete" events also seem to have an any_data whose value() we use. These may be other areas for changes similar to the above. That is, just make e.any_data = e.any_data.value() and then change the associated uses in gnome-terminal.py and default.py to use event.any_data instead of event.any_data.value(). wwalker@ubuntu:~/orca/trunk/src/orca$ find . -name \*.py | xargs grep -n "any_data[.]value[(]" ./scripts/gnome-terminal.py:110: character = event.any_data.value().decode("UTF-8")[0].encode("UTF-8") ./scripts/gnome-terminal.py:139: text = event.any_data.value() ./atspi.py:86: return e.any_data.value().any_data ./atspi.py:104: details = e.any_data.value() ./default.py:2169: character = event.any_data.value() ./default.py:2229: text = event.any_data.value() ./default.py:2290: child = atspi.Accessible.makeAccessible(event.any_data.value())" Joanie said she'd take a look at trying this out this soon (thanks Joanie!).
Having looked at it, what Rich said in comment #7 is correct, namely: > Sometimes when the Navigator window is displayed and we then arrow > up and down in it, we do *NOT* get those events, and therefore can't > speak them. The invalid object problem does crop up impacting access to the tree *initially* (which is not a problem pre at-spi 1.7.14). Fixing that bug enables you to access the tree items initially, but the reported problem of not being able to access those items subsequently remains. Here's a snippet from a full debug.out on a machine without the invalid object problem: vvvvv PROCESS OBJECT EVENT object:state-changed:active vvvvv OBJECT EVENT: object:state-changed:active detail=(1,0) app.name='soffice.bin' name='Navigator' role='frame' state='ACTIVE ENABLED RESIZABLE SENSITIVE SHOWING VISIBLE' relations='' ^^^^^ PROCESS OBJECT EVENT object:state-changed:active ^^^^^ KEYEVENT: type=0 hw_code=104 modifiers=0 event_string=(Down) is_text=True time=1168789592.271361 orca._keyEcho: string to echo: Down KEYEVENT: type=1 hw_code=104 modifiers=0 event_string=(Down) is_text=True time=1168789592.498572 KEYEVENT: type=0 hw_code=104 modifiers=0 event_string=(Down) is_text=True time=1168789592.729526 orca._keyEcho: string to echo: Down KEYEVENT: type=1 hw_code=104 modifiers=0 event_string=(Down) is_text=True time=1168789592.853256 KEYEVENT: type=0 hw_code=104 modifiers=0 event_string=(Down) is_text=True time=1168789593.004088 orca._keyEcho: string to echo: Down KEYEVENT: type=1 hw_code=104 modifiers=0 event_string=(Down) is_text=True time=1168789593.122598 KEYEVENT: type=0 hw_code=104 modifiers=0 event_string=(Down) is_text=True time=1168789593.218257 orca._keyEcho: string to echo: Down KEYEVENT: type=1 hw_code=104 modifiers=0 event_string=(Down) is_text=True time=1168789593.310968 KEYEVENT: type=0 hw_code=104 modifiers=0 event_string=(Down) is_text=True time=1168789593.401698 orca._keyEcho: string to echo: Down KEYEVENT: type=1 hw_code=104 modifiers=0 event_string=(Down) is_text=True time=1168789593.530569 KEYEVENT: type=0 hw_code=98 modifiers=0 event_string=(Up) is_text=True time=1168789593.836535 orca._keyEcho: string to echo: Up KEYEVENT: type=1 hw_code=98 modifiers=0 event_string=(Up) is_text=True time=1168789593.944781 It goes on, but you get the idea. ;-)
Removing target milestone from [blocked] bugs. We have little control over them, so we're better off letting priority and severity be our guide for poking the related components.
I just tried this with OOo dev 3.0 m24(Build:9329) and it's still broken for me. The last two comments on the OOo issue are: ~~~~~~~~~~ ------- Additional comments from pb Thu Jun 26 10:59:24 +0000 2008 ------- pb: not reproducible any longer. Verified by Eric (es), Oliver (obr) and Oliver (od) on cws pba11y01. ------- Additional comments from pb Thu Jun 26 10:59:57 +0000 2008 ------- pb: works -> closed. ~~~~~~~~~~ So I don't know if the fix has yet to be made available in the public builds or if it wasn't actually fixed but instead closed as WFM.
Still broken with OODEV300_m27 build 9336 on my OpenSolaris box. Commented on http://www.openoffice.org/issues/show_bug.cgi?id=70966 and asked them to reopen the bug.
On 24-Mar-2009, Joanie added this comment to the OOo bug: "I just took a look using the latest OOo 3.0 dev build in OpenSolaris 109 using Orca. Looks like it's fixed. Awesome and thanks!" So...we need to confirm the fix with Orca and we can close this bug as FIXED. Joanie - since you did a lot of the legwork and deserve the bgo points for it, I'm assigning this to you.
(In reply to comment #16) > So...we need to confirm the fix with Orca Confirmed in OOo Dev 300m41 (Build 9383) in OpenSolaris 111a. We're presenting the correct info now because we're getting the correct events. Funny how that works.... ;-) > Joanie - since you did a lot of the legwork and deserve the bgo points for it, > I'm assigning this to you. Dunno about the deserving bit, but in the spirit of one less opened bug, I accept the assignment and I am closing this bug. :-) Thanks Will!