Bug 115511 - Description field in customize dialog cannot get focus
Summary: Description field in customize dialog cannot get focus
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.1.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Muhammet Kara
URL:
Whiteboard: target:6.1.0
Keywords: accessibility
Depends on:
Blocks: Customise-Dialog
  Show dependency treegraph
 
Reported: 2018-02-07 11:38 UTC by Regina Henschel
Modified: 2018-03-18 19:02 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2018-02-07 11:38:48 UTC
The Description field in the customize dialog cannot get focus. It is neither reachable with tab traversing nor does it has an access key. The result is, that scrolling its content is only possible with mouse.

Use e.g. the function "Aging" to see a large content, that needs scrolling.
Comment 1 Buovjaga 2018-02-26 19:31:37 UTC
Ok, so this would be in the tabs Menus, Toolbars and Context menus. I reproduce.

For some reason, the Description field is always empty and inactive for me in a master build. I should file a report for that.

Arch Linux 64-bit
Version: 6.0.1.1
Build ID: 6.0.1-1
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Comment 2 V Stuart Foote 2018-02-26 20:16:49 UTC
Unable to navigate with keyboard only into this .UI element of the GUI.

(In reply to Buovjaga from comment #1)
> For some reason, the Description field is always empty and inactive for me
> in a master build. I should file a report for that.
> 

The "off-line" built-in help must be built and installed for this field to populate.

But on longer descriptions, e.g. "Anchor as Character", the widget does get a scroll bar control, but as Regina notes use of the mouse is required. With out gaining focus screen readers will not expose the description.
Comment 3 Muhammet Kara 2018-02-27 05:14:32 UTC
The behavior of the description field was by-choice IIRC. Can't remember the reason though. Maybe Heiko can shed some light on this.

You need to build "--with-help" to see the descriptions.
Comment 4 Heiko Tietze 2018-02-27 08:24:57 UTC
Read only is required because it's a static information. In case of content exceeding the predefined size we should show the vertical scrollbar.
Comment 5 Regina Henschel 2018-02-27 12:27:53 UTC
(In reply to Heiko Tietze from comment #4)
> Read only is required because it's a static information. In case of content
> exceeding the predefined size we should show the vertical scrollbar.

The scrollbar is already there. The problem is, that you cannot use the scrollbar without mouse.
Comment 6 Heiko Tietze 2018-02-27 14:39:24 UTC
(In reply to Regina Henschel from comment #5)
> The scrollbar is already there. The problem is, that you cannot use the
> scrollbar without mouse.

Right, should test things first :-). And actually it perfectly works for me as I can select text and "scroll down" per cursor, which is how those static text fields behave usually.
Comment 7 Buovjaga 2018-02-27 14:45:25 UTC
(In reply to Heiko Tietze from comment #6)
> (In reply to Regina Henschel from comment #5)
> > The scrollbar is already there. The problem is, that you cannot use the
> > scrollbar without mouse.
> 
> Right, should test things first :-). And actually it perfectly works for me
> as I can select text and "scroll down" per cursor, which is how those static
> text fields behave usually.

It does not work for users, who must use the keyboard to focus on the field.
Comment 8 V Stuart Foote 2018-02-27 15:03:39 UTC
(In reply to Heiko Tietze from comment #6)
> (In reply to Regina Henschel from comment #5)
> > The scrollbar is already there. The problem is, that you cannot use the
> > scrollbar without mouse.
> 
> Right, should test things first :-). And actually it perfectly works for me
> as I can select text and "scroll down" per cursor, which is how those static
> text fields behave usually.

Does not work with Keyboard only movements--unable to gain focus without a mouse click--making it an accessibility issue, and a nuisance otherwise.  Combination of F6, <TAB>, or <Cursors> must move through every component of the GUI--obviously better if it is consistent across the UI--but at a minimum all must be reachable without needing to position and click a mouse pointer.
Comment 9 Heiko Tietze 2018-02-27 15:44:53 UTC
But that means not the control itself is badly implemented but the buddy relation to its label is missing. Piece of cake of Muhammet.
Comment 10 Muhammet Kara 2018-03-16 13:40:24 UTC
(In reply to Heiko Tietze from comment #9)
> But that means not the control itself is badly implemented but the buddy
> relation to its label is missing. Piece of cake of Muhammet.

There seems to be a problem with the implementation of the widget which causes it to be excluded from tab navigation. Enabling access with an accelerator is a quick fix on the .ui file though.

I'll manually set the WB_TABSTOP bit to make sure it is included in tab navigation.
Comment 11 Muhammet Kara 2018-03-16 13:58:49 UTC
Patch is on gerrit if you wouldlike to test: https://gerrit.libreoffice.org/#/c/51426/
Comment 12 Buovjaga 2018-03-16 18:01:48 UTC
(In reply to Muhammet Kara from comment #11)
> Patch is on gerrit if you wouldlike to test:
> https://gerrit.libreoffice.org/#/c/51426/

I confirm it is now focusable and scrollable with keyboard.
Comment 13 Commit Notification 2018-03-18 18:53:13 UTC
Muhammet Kara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=86b160886f6d5580a84f5008682cc93fa8c63e39

tdf#115511: Make the description field keyboard-accessible

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.