Bug 108687 - Form option buttons and other form fields not reachable with tab key
Summary: Form option buttons and other form fields 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
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
: 143818 (view as bug list)
Depends on:
Blocks: a11y, Accessibility Form-Controls
  Show dependency treegraph
 
Reported: 2017-06-22 00:40 UTC by rafael.linux.user
Modified: 2024-05-31 15:28 UTC (History)
7 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 Comment hidden (obsolete)
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.
Comment 32 Justin L 2020-05-07 05:28:51 UTC
Very important in the consideration of this bug is a LO 7.0 change by Caolan for fallout bug 132581.
https://gerrit.libreoffice.org/c/core/+/93567
Comment 33 Justin L 2020-11-14 06:50:40 UTC
repro 7.1+
Comment 34 Christophe Strobbe 2021-08-11 00:54:44 UTC
While I can confirm that the issue still exists in LibreOffice 7.1.3.2 (on OpenSUSE Leap 15.2), I would like to point out that the file attachment does not demonstrate how forms are intended to be filled in. As the LibreOffice Writer Guide points out at https://books.libreoffice.org/en/WG71/WG7118-Forms.html#toc24 

[begin quote]
If you plan to send this [form] out to other people to complete, you probably want to make the document read-only so that users would be able to fill in the form but not make any other changes to the document.

To make the document read-only, select File > Properties, select the Security tab and enable Open file read-only.
[end quote]

A similar feature exists in Microsoft Word ("Restrict Editing", so the form can only be filled in, not modified).

However, when a Writer form is saved in read-only mode and re-opened, the form fields are not keyboard accessible, as I have reported in bug 143818: https://bugs.documentfoundation.org/show_bug.cgi?id=143818

With the document in read-only mode, once you use the mouse to put the cursor into the first text field, you can cycle through all the form fields except the radio buttons (just as in unprotected mode).
Comment 35 rafael.linux.user 2021-08-12 00:13:55 UTC
Thank you for your test. I found a curious issue: If you select any of the radio buttons, and you begin to cycle among all fields, user can jump even the SELECTED radio button. So maybe it's something to take into account to fix issue.
Comment 36 Timur 2021-08-16 09:07:57 UTC
*** Bug 143818 has been marked as a duplicate of this bug. ***
Comment 37 Christophe Strobbe 2021-08-16 13:43:16 UTC
(In reply to rafael.linux.user from comment #0)

I have reworded the bug's title from "Form option buttons not reachable with tab key" to "Form option buttons and other form fields not reachable with tab key" since this accessibility issue appears to apply to all form fields.

As I mentioned in comment #34, this needs to be tested after saving the form in read-only mode and reopening the document.

This clarification was suggested by Timur in bug 143818 at https://bugs.documentfoundation.org/show_bug.cgi?id=143818#c5 .
Comment 38 Justin L 2023-05-05 23:56:38 UTC
repro 7.6+
Comment 39 Justin L 2023-05-05 23:58:40 UTC
For anyone facing this problem, I recommend using the new content controls when you design your form. Any problems found there are much more likely to be fixed. Plus, they are quite flexible and have a tabIndex to allow navigation order.
Comment 40 Justin L 2024-05-31 15:28:09 UTC
repro 24.8+