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
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.
Created attachment 134402 [details] Use tab to jump from control to control You will notice that tab key ignore "option buttons"
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
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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
Fantastic. Now it's working in 6.0.5 version (tried in appimage)
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 ...
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.
(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.
The problem with the tabstop is that both option buttons have the same name. See duplicate (but complex) bug 116702. The other problem is that the group name is blank, so once the option buttons are selected, arrow keys etc don't move the selection to other option boxes. That might be fixable, so lets focus the bug report on that (where the option buttons have different names - and so tab reaches the group, but then no keyboard keys move between the options).
(In reply to Justin L from comment #10) OK - I was all wrong. As rafael clearly stated, the tab problem is because neither of them is selected. If one is selected, then the tabstop jumps to that one. Additionally, my comment about groupname was all wrong too. Sorry for the noise.
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...
proposed fix at https://gerrit.libreoffice.org/62822
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.
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.
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.
(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).
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.
(In reply to Alex ARNAUD from comment #18) It is fixed in LibreOffice 6.2. Are you using LibreOffice 6.2?
(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.
It's solved in version 6.2 (I tested it on AppImage). Thank you to all testers and developers.
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.
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.
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.
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.
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.
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.
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.
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.
As the fix is now reverted everywhere.
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.
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
repro 7.1+
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).
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.
*** Bug 143818 has been marked as a duplicate of this bug. ***
(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 .
repro 7.6+
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.