Apache OpenOffice (AOO) Bugzilla – Issue 58139
Document view canvas for should have state SHOWING
Last modified: 2013-08-07 14:42:49 UTC
The widget path heirarchy to widgets that are "visible" and "showing" should be made have nodes with both of these states. Specifically the Document view canvas should include the "showing" state. GOK (gnu/gnome onscreen keyboard) requires this to be the case. Until this is fixed GOK will not be able to expose the document editing text area properly to its users. I will attach a screenshot to assist in fixing this quickly.
Created attachment 31621 [details] at-poke showing the state set for the errant canvas widget
I recommend the keyword: accessibility for this bug.
HI->ES: Please take a look.
ES->OBR: please have a look
.
GOK users are used to being able to select text components via a dynamically* created GOK key. GOK searches the widget tree to find such components and creates on-screen keys to represent them. With SO Writer, the main document area is not currently presented as a GOK key because GOK halts it's search at this branch because the parent canvas widget does not have 'SPI_STATE_SHOWING'. *NOTE: The dynamic GOK keys reduce the number of steps required for a user to get their job done. (e.g. for a user with mobility impairment, selecting the 'text' gok key is nicer than perhaps selecting the gok 'tab' key 5 times, saving minutes of effort).
The problem seems to be that the document view does not to have "VISIBLE" state when asked the first time (during opening the window), but never sends a state changed event when this changes. The UNO <-> Java bridge caches these states, so it relies on those state changes to be send. This will not be the case for the UNO<->ATK bridge, which makes a fix less urgent.
Good. Just to clarify, the at-spi provides both states SPI_STATE_VISIBLE, and SPI_STATE_SHOWING (among others of course). As long as the UNO->ATK bridge results in this canvas having both these states GOK will pay attention. Thanks for investigating this bug.
At the moment gok is asking, the document view has both states set, so they are correctly exposed by the at-spi bridge. The problem with the java bridge is that - in order to mimic the behavior of Java objects as close as possible - it needs to keep a number of states in sync. Java objects are "showing" if they are "visible" and all their parents (if any) are "showing" - so being out of sync regarding "visible" is the problem here.
adjust target milestone to OOo 2.x
target 2.4
Due to the fact that under Gnome the ATK bridge used, this defect does not exist any more under Gnome. But, it still exists under Windows, where the Java bridge is used. proposed solution: adjust implementation in class <SwAccessibleDocumentView> in order to assure that the state change is send, when the visible state changes.
OD->OBR: Current investigation reveals that the Writer implementation of the Document View always is in visible state. Perhaps one of the parents of the Document View isn't in showing state and thus, the Document View itself isn't showing. The showing state of the Document View depends on a flag. But, in general cases this flag is also true. Exception: The application is started after a crash and the recovery dialog comes up. After this an empty text document is opened, whose Document View isn't in showing state. As discussed, please take over for further investigations.
Actually the state SHOWING gets added to the AccessibleStateSet if it is present in the corresponding UNO XAccessibleStateSet. Only the FOCUSED state gets overwritten by the internal state of the Java wrappers. But in debug mode, SHOWING state is compared with the corresponding internal state of Java wrapper. Both states are in sync (true) when opening an existing document, but when creating a new document (e.g. by launching soffice -writer), SHOWING is not in the UNO state set (and thus not in the Java state set), but should be.
Which by the way implies that my initial investigation was either incorrect or is outdated. So this bug probably still/again affects GOK even with the UNO <-> ATK bridge.
Now, the defect cause is clear - thx to OBR. fixed in cws sw8u10bf03 - changed file: /sw/source/core/access/accdoc.cxx, 1.31.116.1 defect cause: The initial visible area for the Writer a11y implementation of the document view is empty. Thus, internal showing state is not set. When the visible area of the document view is set, the internal showing state is not updated.
OD->ES: Checked in internal installation set of cws sw8u10bf03 - please verify.
Verified on Windows with JavaMonkey in CWS sw8u10bf03.
This issue is closed automatically and wasn't rechecked in a current version of OOo. The fixed issue should be integrated in OOo since more than half a year. If you think this issue isn't fixed in a current version (OOo 3.1), please reopen it and change the field 'Target Milestone' accordingly. If you want to download a current version of OOo => http://download.openoffice.org/index.html If you want to know more about the handling of fixed/verified issues => http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues