Download it now!
Bug 108687 - Form option buttons not reachable with tab key
Summary: Form option buttons not reachable with tab key
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks: a11y Form-Controls
  Show dependency treegraph
 
Reported: 2017-06-22 00:40 UTC by rafael.linux.user
Modified: 2019-11-14 16:53 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Use tab to jump from control to control (11.58 KB, application/vnd.oasis.opendocument.text)
2017-06-30 01:02 UTC, rafael.linux.user
Details
radioTabStop.diff: slightly hacky fix with debug (2.93 KB, patch)
2018-11-03 13:02 UTC, Justin L
Details
tabstop.debug.patch (3.12 KB, patch)
2019-11-14 09:39 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rafael.linux.user 2017-06-22 00:40:40 UTC
Description:
After creating a form with "Option buttons", they are not reached when using the tab key if they are empty.

Steps to Reproduce:
1.Create form
2.Insert button options without default option
3.Use tab to reach the option buttons

Actual Results:  
If option button is not selected, option button are not reached. You need to use mouse pointer to select it.

Expected Results:
To be reachable using tab  key.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Buovjaga 2017-06-28 16:33:47 UTC
I tried to repro, but am not sure how to create a case you are referring to. Please attach a document.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the document.
Comment 2 rafael.linux.user 2017-06-30 01:02:35 UTC
Created attachment 134402 [details]
Use tab to jump from control to control

You will notice that tab key ignore "option buttons"
Comment 3 Buovjaga 2017-06-30 12:21:26 UTC
Confirmed.

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha0+
Build ID: 98befbb26217b0bf3f35354e418a355280c52cfc
CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on June 29th 2017

Arch Linux 64-bit
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 4 QA Administrators 2018-07-19 02:40:59 UTC Comment hidden (spam)
Comment 5 Buovjaga 2018-07-19 12:33:07 UTC
No idea, why you closed, because this is not fixed/worksforme. I can reproduce also from scratch.

Arch Linux 64-bit
Version: 6.2.0.0.alpha0+
Build ID: 860a9daf2b45942a4b10ff22d36aa3fe29be19f4
CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on July 14th 2018
Comment 6 rafael.linux.user 2018-07-20 13:45:57 UTC
Fantastic. Now it's working in 6.0.5 version (tried in appimage)
Comment 7 rafael.linux.user 2018-07-20 13:51:48 UTC
Sorry, I must be more explicit: I closed in first place incorrectly, cause I forgot to check precisely the option buttons. Then I downloaded the 6.0.5 appimage and checked correctly the option buttons: The cursor jumps perfectly from one text input to a option button and so on so, for me, the bug is fixed.

So, is it not correct that I close the bug in this case?

You talk about 6.2.0.0.alpha0+ version, but I don't know why ...
Comment 8 Buovjaga 2018-07-22 07:16:31 UTC
It is not working for me in 6.0.5 or 6.2. The radio buttons do not get focus with tab. I also tried gtk2, kde4 and gen VCL backends.
Comment 9 Alex ARNAUD 2018-07-26 12:14:51 UTC
(In reply to rafael.linux.user from comment #7)
> Sorry, I must be more explicit: I closed in first place incorrectly, cause I
> forgot to check precisely the option buttons. Then I downloaded the 6.0.5
> appimage and checked correctly the option buttons: The cursor jumps
> perfectly from one text input to a option button and so on so, for me, the
> bug is fixed.
> 
> So, is it not correct that I close the bug in this case?
> 
> You talk about 6.2.0.0.alpha0+ version, but I don't know why ...

I also couldn't reproduce the correction. Could you tell me the exact you're doing?

Best regards,
Alex.
Comment 10 Justin L 2018-11-01 17:22:20 UTC Comment hidden (no-value)
Comment 11 Justin L 2018-11-01 17:35:07 UTC Comment hidden (no-value)
Comment 12 Justin L 2018-11-03 13:02:23 UTC
Created attachment 146266 [details]
radioTabStop.diff: slightly hacky fix with debug

Unlike my patch above, it might be as simple as ALWAYS telling radiobuttons to accept accept a tabstop, just like checkboxes currently do. In practice it seems to work just fine...
Comment 13 Justin L 2018-11-03 19:10:05 UTC
proposed fix at https://gerrit.libreoffice.org/62822
Comment 14 Commit Notification 2018-11-05 09:02:44 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/f2cd1c3c7cce2699d1341f726fc90cf30b52612c%5E%21

tdf#108687 vcl: always enable tabstop on radio buttons

It will be available in 6.2.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 15 Justin L 2018-11-05 14:54:41 UTC
Caolan's gerrit review comment is useful:
I definitely wouldn't expect there to be any platform dependent behavior here, so if it works on one I expect it to work on all.

We have proper "tabstop groups" now, while in the past being part of a group was simply "there's another peer window before this one that is also a radiobutton and is not explicitly marked as not in a group".

Anything that is a .ui probably works the "new" way of explicit groups, so its probable only forms and/or starbasic macro gui descriptions rely on the "implicit" grouping, maybe there is some odd edge case now of two sets of radio button groups beside eachother that might change in behavior, but they probably didn't work right in some other way.
Comment 16 rafael.linux.user 2018-11-06 00:30:59 UTC
I'm sorry. I said in my last post to this thread is was solved, but IT'S NOT. The problem is still present in latest stable version (for OpenSUSE 15).

My apologizes.
Comment 17 Justin L 2018-11-06 05:03:14 UTC
(In reply to rafael.linux.user from comment #16)
> I'm sorry. I said in my last post to this thread is was solved, but IT'S
> NOT.
Fixed as per automatic comment 14. It will be available in 6.2.0. It will not be backported to earlier, stable versions (which comment 15 indicates still could cause problems in edge cases, so testing time is required).
Comment 18 Alex ARNAUD 2019-02-16 16:49:43 UTC
Hello Julien,

I think we've not seen the case we're talking about. We're three blind people and we can't confirm on LibreOffice daily build.

Could you tell us how without the mouse you can enter inside the form item ? We don't think it is possible because we can't use the mouse. We confirm what rafael told us. We're on Debian GNU/Linux 9 "Stretch" or Debian Sid, we're using the VCL GTK3.

Best regards,
Alex.
Comment 19 Justin L 2019-02-16 16:51:28 UTC
(In reply to Alex ARNAUD from comment #18)
It is fixed in LibreOffice 6.2.  Are you using LibreOffice 6.2?
Comment 20 Buovjaga 2019-02-16 17:45:22 UTC
(In reply to Justin L from comment #19)
> (In reply to Alex ARNAUD from comment #18)
> It is fixed in LibreOffice 6.2.  Are you using LibreOffice 6.2?

The problem described in the report is fixed. It is true that I have to focus with mouse in the text field, but this is an older problem. I was unable to find an existing report.
Comment 21 rafael.linux.user 2019-02-18 00:15:07 UTC
It's solved in version 6.2 (I tested it on AppImage). Thank you to all testers and developers.
Comment 22 Alex ARNAUD 2019-02-18 13:07:45 UTC
I move this as verified fixed as rafael has stated that it works.

We'll fill another issue about the fact form field are not focusable by keyboard.

Best regards,
Alex.
Comment 23 Commit Notification 2019-06-10 07:57:43 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/505f0c6c5a650c403f1a6d6090cebc579affb5b7%5E%21

Revert "tdf#108687 vcl: always enable tabstop on radio buttons"

It will be available in 6.2.5.

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

Affected users are encouraged to test the fix and report feedback.
Comment 24 Justin L 2019-06-10 08:13:25 UTC
This issue will NOT be fixed in LO 6.2 stable (starting with 6.2.5). The regression of bug 125609 is fairly serious, since it can change the selected value just by tabbing through the choices. Those who really want this bug "fixed" should stick with LibreOffice 6.2.4 for now, or switch to LO 6.3. 

It looks like it is just exposing an existing problem of groups not being properly defined, but there are other problems that were created in 6.3 radio buttons. For now I'll keep the patch in LO 6.3, but if it isn't fixed in a couple of months, I'll revert from there as well.
Comment 25 Commit Notification 2019-07-15 12:56:51 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/+/4109dfff009f017e8994ea0a57119e79291ca2c8%5E%21

Revert "tdf#108687 vcl: always enable tabstop on radio buttons"

It will be available in 6.3.0.2.

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

Affected users are encouraged to test the fix and report feedback.
Comment 26 Justin L 2019-07-15 16:08:49 UTC
This issue will NOT be fixed in LO 6.3, but should be fixed in next year's 6.4 since I found the source of the problem exposed in bug 125609. However, there could be side effects with that patch, so I have no intention of rushing that fix into production.
Comment 27 Justin L 2019-11-14 09:39:59 UTC
Created attachment 155798 [details]
tabstop.debug.patch

bug 128749 is a new regression identified against the fix for this bug that doesn't look easy to fix. bug 128625 was another one based on incorrect setting usage, but that might be replicated in many other extensions etc... A better fix for this bug is needed.
Comment 28 Commit Notification 2019-11-14 11:52:27 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/bce68bef088f1adb59ff199b2fc44f676d64e749

Revert "tdf#108687 vcl: always enable tabstop on radio buttons"

It will be available in 6.5.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 29 Commit Notification 2019-11-14 15:10:00 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/464b42af4055870322a1af65eaf590683b4776e7

Revert "tdf#108687 vcl: always enable tabstop on radio buttons"

It will be available in 6.4.0.1.

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

Affected users are encouraged to test the fix and report feedback.
Comment 30 Jan-Marek Glogowski 2019-11-14 15:29:01 UTC
As the fix is now reverted everywhere.
Comment 31 Justin L 2019-11-14 16:53:26 UTC
I reviewed the patches made to solve the other regression reports, and I think they can all stay intact, but if need be they could also be reverted now.