Description: Form fields are not accessible using only the keyboard; they cannot be reached using the TAB key (or any other key, apparently) and therefore cannot be filled in. Steps to Reproduce: 1. In a Writer document, add a few form fields, such as a text entry field (e.g. for the user's name), a numeric field, a date field and a set of option buttons. 2. Go to File -> Properties -> Security and check the option "Open file read-only". This makes sure that users just fill in the field instead of modifying the form (as explained in Chapter 15 of the LibreOffice Writer Guide). 3. Save the file, close it and reopen it. 4. Without using the mouse, try to reach any of the form fields using the TAB key; none of the fields receives focus. Move around the document using the arrow keys; the cursor moves through any text above and below the fields and through the labels, but the form fields are ignored. 5. When using the mouse to put the focus into the first field, it becomes possible to TAB to some of the other fields (the numeric field and the date field) but not the set of option buttons / radio buttons). Actual Results: When using only the TAB key, none of the form fields receive focus; it is impossible to fill the form without using the mouse to put the cursor into the first field or on the set of radio buttons. Expected Results: Using the TAB key should cycle the focus through the form fields in the order in which they are arranged in the document. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.3.2 / LibreOffice Community Build ID: 10(Build:2) CPU threads: 8; OS: Linux 5.5; UI render: default; VCL: kf5 Locale: en-GB (en_GB.utf8); UI: en-GB Calc: threaded
I have now reproduced this issue on Windows 10, which suggests that this is not a Linux-only issue. I have reproduced the issue using LibreOffice 7.1.4.2 with the same results as under Linux. In addition, I have also reproduced the issue using OpenOffice.org Writer 3.3, again with the same results, which suggests that the issue was probably inherited from OpenOffice.org rather than being a regression. In each of these cases, I recreated the same document with the same form fields from scratch: a name field (plain text), a numeric field, a date field and a group box with option buttons (gender: male, female, other). Both under Linux and Windows, the form fields could not be tabbed into. When the mouse was used to put the cursor in the first text field, tabbing to the numeric field and the date field became possible, but the group box remained inaccessible. After selecting one of the radio buttons, tabbing between the group box and the other fields became possible. The behaviour was the same regardless of platform. The anchoring of the form fields (e.g. "To character" or "As character") did not make any difference.
confirm in Version: 7.1.5.2 (x64) / LibreOffice Community Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: en-US (ru_RU); UI: en-US Calc: CL
Rule of thumb is search before reporting and confirming. Seems like a duplicate, please explain if not. *** This bug has been marked as a duplicate of bug 108687 ***
Timur, bug 108687 applies only to option buttons (or radio buttons, as they are known on the web). My bug report applies to form fields generally (text entry, numeric field, date entry, radio button, checkbox, list box). In addition, my bug report describes the crucial step of making a form read-only (before sending it out for people to fill it out), whereas bug 108687 makes no mention of this step. From my point of view, bug 108687 describes a subset of my bug report.
(In reply to Christophe Strobbe from comment #4) > From my point of view, bug 108687 describes a subset of my bug report. So please write this there and explain. We clarify existing reports, opening additional one makes no use. If only some parts are resolved, then it can be rechecked and reopened (i.e. status New)