Bug 74232

Summary: [Accessibility] After applying a formatting style, focus moves to the formatting toolbar when navigating the document
Product: LibreOffice Reporter: Marco Zehe <marcozehe>
Component: UIAssignee: Not Assigned <libreoffice-bugs>
Status: RESOLVED WORKSFORME QA Contact:
Severity: major    
Priority: medium CC: jmadero.dev, michael.meeks, mst.fdo, vstuart.foote
Version: 4.2.0.4 release   
Hardware: x86-64 (AMD64)   
OS: Windows (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 60251    
Attachments: simple odt writer document with changing heading and font sytles

Description Marco Zehe 2014-01-30 15:58:16 UTC
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.
Comment 1 Marco Zehe 2014-01-30 18:46:05 UTC
I just installed a 4.3.0 dev build from January 30, 2014, and the problem is fixed there. Closing as WorksForMe.
Comment 2 V Stuart Foote 2014-01-31 00:32:39 UTC
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.
Comment 3 V Stuart Foote 2014-01-31 00:42:00 UTC
@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.
Comment 4 V Stuart Foote 2014-01-31 00:45:15 UTC
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.
Comment 5 V Stuart Foote 2014-01-31 01:20:04 UTC
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
Comment 6 V Stuart Foote 2014-01-31 01:21:43 UTC
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
Comment 7 Marco Zehe 2014-02-16 07:47:02 UTC
This is still a problem in LibreOffice Version: 4.2.1.1
Build-ID: d7dbbd7842e6a58b0f521599204e827654e1fb8b
Comment 8 Marco Zehe 2014-02-18 12:50:58 UTC
(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.
Comment 9 Marco Zehe 2014-03-06 16:13:43 UTC
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!
Comment 10 Michael Meeks 2014-03-06 20:38:29 UTC
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.
Comment 11 Marco Zehe 2014-03-07 10:46:15 UTC
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.
Comment 12 Joel Madero 2014-11-06 00:31:26 UTC
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!

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.