Apache OpenOffice (AOO) Bugzilla – Issue 92103
No a11y events when expanding/collapsing items in navigator
Last modified: 2013-08-07 14:44:00 UTC
1) Run OOo and create a new document with several headings in it. 2) Press F5 to bring up the Navigator window and then Alt+F6 to put focus on the navigator. 3) Arrow to the "Headings" item and press left/right to contract/expand the item. If you watch the events being delivered by OOo (say via the accerciser application), you will notice that no events are being delivered by OOo when you expand/contract the Headings item. I believe object:state-changed:expanded events should be delivered. Thanks!
OOo 3.2
Trackback to the Orca bug: http://bugzilla.gnome.org/show_bug.cgi?id=356060
OD: Please have a look
Sorry, I forgot to set confirmed.
Ok, confirming issue as ES already wanted to do
OD->williewalker: I am working on with issue. But, I have got a problem. The accessible objects, which represent the items in the navigator's tree, are transient. Thus, it does not make sense to emit events for them - no one would listen to a newly created accessible object. The accessible object, which represents the navigator's tree, could emit an event stating that the expanded state of one of its children has changed including a newly created accessible object of this child in this event - something like "object:descendant-state-changed-expanded". Would this be acceptable for you? Do you have another suggestion?
williewalker->OD: the AT-SPI event model is such that one registers for event types in general instead of registering for events on specific objects. So, it should be OK to emit object:state-changed:expanded events for these objects. A GTK+ example of where we see this can be found in the gtk-demo application (/usr/demo/jds/bin/gtk-demo on OpenSolaris). The "Icon View" item in the tree table is an accessible table cell object with the EXPANDABLE and TRANSIENT states and it emits the appropriate events. Here's some examples from accerciser when I expand/collapse the object: object:state-changed:expanded(1, 0, None) source: [table cell | Icon View] application: [application | gtk-demo] object:state-changed:expanded(0, 0, None) source: [table cell | Icon View] application: [application | gtk-demo]
Ok. Thus, the proposed solution in OOo and OOo's ATK bridge will be: - emit events for expanding/collapsing of a certain tree item in OOo at the accessible object representing the navigator's tree - the event will contain a newly created OOo accessible object representing the tree item. - convert these events in the ATK bridge to events of newly created ATK objects representing the corresponding tree item.
Just for clarification - how does the OOo implementation treat transient objects? My understanding of transient objects is that they should tend to persist as long as they are rendered on the screen. So, for example, if one arrows up and down the transient items of a tree, the accessible objects should remain the same as long as they are still painted on the display. Thus, changing the state of the object, such as expanding or collapsing it, should not cause the old accessible peer for that object to be destroyed and a new one created. Instead, the same accessible should be used.
In this case the internal accessible object representing a navigator's tree item is not hold by OOo core code itself. Probably, a reference is hold by the bridge, which would keep the accessible object alive. But, I do not think that this is the case for transient marked accessible objects. Thus, the typical life time of an accessible object representing a navigator's tree item is very short, even if the list item is visible on the screen. E.g., Each call to <[accessible object of tree]::getAccessibleChild( i )> creates a new accessible object for the tree item.
Emitting the object:state-changed:expanded is still the appropriate thing to do. Given that there are unknowns in the implementation, let's see what happens with the life cycle of the objects. We have code in Orca that attempts to deal with different accessibles being used for the same visual object on the screen. So, if we get different accessibles in this case, Orca's code might work and/or we might be able to make it work. Thanks!
Yes, I am also be sure that it will work.
adding new constants to com::sun::star::accessibility::AccessibleEventId indicating that a list box entry has been expanded respectively collapsed - change file: /offapi/com/sun/star/accessibility/AccessibleEventId.idl, rev. 271454
adding new vcl event ids VCLEVENT_LISTBOX_ENTRY_EXPANDED and VCLEVENT_LISTBOX_ENTRY_COLLAPSED - changed file: /vcl/inc/vcl/vclevent.hxx, rev. 271469
emit vcl events list box entry expanded resp. collapsed - changed file: /svtools/source/contnr/svtreebx.cxx, rev. 272330 process vcl events list box entry expanded resp. collapsed in order to emit corresponding accessibility events - changed file: /accessibility/source/extended/accessiblelistbox.cxx, rev. 272331 map accessible events list box entry expanded resp. collapsed to corresponding atk events - changed file: /vcl/unx/gtk/a11y/atklistener.cxx, rev. 272333
OD->ES: Checked in internal installation set of cws swa11y32_2nd - please verify
This fix has been confirmed by the Orca team using the swa11y32_2nd_en-US_SolarisIntel.tar file Thomas Lange made for me (300m51(Build:9408)[CWS:swa11y32_2nd]). Many thanks!
Thanx for verifying!
Fixed and integrated => closing now..