With the new IAccessible2 support, when formatting a paragraph in Writer via the Formatting Styles toolbar, and then returning to that paragraph, focus is pulled away from the document into the toolbar items, so one can no longer read the actual text. Steps to reproduce: 1. Enable the IAccessible2 support and use LibreOffice with the NVDA screen reader. 2. Create a new Writer document. 3. Type a paragraph with some text. 4. press Enter twice. 5. Type some more text and press Enter. 6. Go back to the text typed in step 5 and select it. 7. Access the Styles button in the Formatting toolbar, and select Heading\Heading 1 as the new style. 8. Press Enter to select and close. 9. Notice the screen reader speaks something from the formatting toolbar. 10. Press UpArrow to go to the blank line above the previously selected and newly formatted text. 11. Go back down with DownArrow. Expected: I expect to hear the text I typed. Actual: Focus is pulled away to the formatting toolbar onto the Font Size combobox instead. 12. Move the mouse away from the toolbar. Expected: At least this should now clear the focus. Actual: Problem persists. As soon as cursr hits this paragraph, focus for screen readers is pulled away from the document area into the toolbar, and one can not read the text of that paragraph. 13. To verify, go up to the first line you typed. Result: This is standard text, and thus the focus stays in the document area. Note that focus actually never leaves the document area, but focus events are fired on the Font Size combobox on the Formatting toolbar, making it appear that focus has moved when it actually hasn't.
I just installed a 4.3.0 dev build from January 30, 2014, and the problem is fixed there. Closing as WorksForMe.
On Windows 7 sp1, 64-bit with NVDA (2013.2) AT active Version: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71 Confirming, this incorrect behavior in the 4.2.0.4 release that when transitioning between paragraphs having different Sytle/Font/Size styling applied. Using cursor key movements between adjacent paragraphs, IAccessible2 object hangs in the Formatting tool bar in the 'font size' option pane combo box, on the 'transient' list element assigned the paragraph being exited. Or when transitioning to an paragraph with a change in font, the IAccessible2 object hangs in the 'font name' option pane combo box, on the 'transient' list element assigned to the prior paragraph. =-=-=Workaround=-=-= However, issuing a <CRTL>F6 key does return program focus to the document view. Providing a reasonable work around. In fact, for most menu actions--the <CRTL>F6 sequence is preferentially the way to return focus to the document view.
@Marco, Thanks for testing and posting! (In reply to comment #1) > I just installed a 4.3.0 dev build from January 30, 2014, and the problem is > fixed there. Closing as WorksForMe. I'm reopening. I can understand if you now prefer to work with IAccessible2 builds implemented in master, but we still need to resolve issues found in the 4.2 release for the rest of the user base. Especially as we consider IAccessible2 a work in progress. There are liable to be other similar issues between the 4.2.0.4 release and the builds of master 4.3.0.0alpha+ A challenge with this focus tracking issue is to figure out what code got corrected on master, so it can be patched for the 4.2.1 builds. Please keep a copy of 4.2.0 release installed, if only for testing.
Created attachment 93094 [details] simple odt writer document with changing heading and font sytles moving from paragraph to paragraph with AccProbe tracking will show transient hangs of IAccessible2 objects on 'font name' or 'font size' combo box list elements.
On Windows 7 sp1, 64-bit with NVDA (2013.2) and AccProbe monitoring IAccessible2 Verified this has not yet been patched on the 4.2 branch. Version: 4.2.1.0.0+ Build ID: 9a19e8d838753128504274e1885eb3ce8ec1dbb8 TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-01-30_00:20:59
Also can confirm that it has been corrected in builds of master. Version: 4.3.0.0.alpha0+ Build ID: a904aa609dddb80a44cf34a5e4299efe0dc2c49f TinderBox: Win-x86@39, Branch:master, Time: 2014-01-30_05:15:33
This is still a problem in LibreOffice Version: 4.2.1.1 Build-ID: d7dbbd7842e6a58b0f521599204e827654e1fb8b
(In reply to comment #2) > =-=-=Workaround=-=-= > However, issuing a <CRTL>F6 key does return program focus to the document > view. Providing a reasonable work around. The problem here is that focus actually never leaves the document area. Only IAccessible pretends that it did. When arrowing left and right within the paragraph, no selection is changed in the toolbar control that supposedly has focus.
This is still an issue in LibreOffice Version: 4.2.2.1 Build-ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f Is anyone willing to take a look at why this is broken in the 4.2.x branch? This along with bug 74234 is still preventing me (and possibly others) from using LibreOffice release/beta versions productively. And always using the 4.3-dev builds feels like walking on a minefield. I would be willing to help with testing, but don't know enough about the code or the branch mechanism to find the errors myself. Help would really be appreciated!
So - I guess this is mostly around working out what patch to back-port to the 4-2 branch to fix this from master =) We could bibisect that of course - or just try a few likely suspects. Do you have a libreoffice-4-2 build to try things out inside ? I tried: git log libreoffice-4-2-branch-point..origin/master --grep=focus which might have one or two helpful bits there (they may of course be already on libreoffice-4-2 hard to know until you log there / cherry-pick). Could it be Tamas's; commit 5b1e68bd852cac4534c5ce2e548187dce1d4561a Author: Zolnai Tamás <tamas.zolnai@collabora.com> Date: Wed Jan 29 21:07:42 2014 +0100 but not sure ! =) failing that - the hard way to find it is to use a git bisect to find it (or better bibisect) but that's missing for Windows I believe. HTH.
Hm, if I execute a search like you suggested above, but replace it with "accessib", for example, instead of "focus", I get all sorts of WinAccessibility-related commits, but can't see which branch they went to. Again: This is less about keyboard focus actually going somewhere when arrowing through the document, but rather about the WinAccessibility part lying to screen readers about where the focus went to. Probably because of some erroneous focus event being fired on the comboboxes. It also doesn't explain bug 74234.
4.2 is EOL - if I understand this correctly it's fixed in 4.3 and was just looking for a backport. No one did a bibisect or tracked it down in time. Closing as WFM. If I read this wrong please set to NEW and explain what else can be done. Again 4.2 is EOL so that point is moot. Thanks all!