Summary: | [Accessibility] After applying a formatting style, focus moves to the formatting toolbar when navigating the document | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Marco Zehe <marcozehe> |
Component: | UI | Assignee: | 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
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! |
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.