When creating a PDF Form in writer, it seems not possible to get the correct behavior from option buttons. They either tab correctly but too many can be selected, or do not tab but are mutually exclusive when selected by mouse clicks. The "Group Name" field has no effect; the "Name" field must match to get mutually exclusive selection, but then the controls are ambiguously named.
Steps to Reproduce:
1. Create 2 option buttons in Writer. Label these "New" and "Renew". Give each of them the group name "renewalStatus" Give them the same or different names, depending on what behavior you want.
2. Export as a PDF form
3. Try using the buttons in Acrobat reader, using tabs or mouse to highlight, and spacebar or click to select. Try to select each button to see whether the other turns off.
When trying to create a pdf form using the writer application, the option buttons must have the same "name" in order to toggle correctly. This is highly counterintuitive, at least to me: They should have the same "group name," but each should have a different "name." For instance, if I display mutually exclusive options with labels "new member" and "renewing member" as radio buttons, these buttons could have names like "newMember" and "renewingMember" and could belong to a group called "renewalStatus." Alternatively, the buttons in this group could be named "renewstatus1" and "renewstatus2." However many buttons I put in the "renewalStatus" group, only one should highlight at a time. When I set up a form this way, and assign a tab order to the option buttons, tabbing floats through the group as expected. Unfortunately, all of the mutually exclusive options can be selected by pressing the spacebar as each option is highlighted, or using the mouse, so that at the end all of the options are selected. In fact, it is hard or impossible to deselect an option.
Changing the option buttons so that all share the same "name," regardless of "group name" causes the mouse selection to work properly, but now tabbing only touches the first option in the group: the next tab skips the rest of the group. This is not right either.
Bugs 79542 and 85339 report similar behaviors.
The correct behavior, IMO, would be for the "Group name" to identify a set of mutually exclusive options; for the tab to float through these options in tab order, and for the space bar to select the highlighted option while deselecting all other options sharing the group name, and for mouse clicks to select the target and deselect everything else sharing the group name; meanwhile, any scripts or macros can refer to each option "name" to obtain an unambiguous status (which seems impossible if all of the options have the same "name").
User Profile Reset: No
I encountered this in 188.8.131.52, and it persists in 184.108.40.206. I have not checked it in 6, as I try not to be on the bleeding edge.
Build ID: 4014ce260a04f1026ba855d3b8d91541c224eab8
CPU threads: 8; OS: Mac OS X 10.13.3; UI render: default;
Locale: en-US (en_US.UTF-8); Calc: group
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/604.5.6 (KHTML, like Gecko) Version/11.0.3 Safari/604.5.6
(In reply to WS from comment #0)
> Steps to Reproduce:
> 1. Create 2 option buttons in Writer. Label these "New" and "Renew". Give
> each of them the group name "renewalStatus" Give them the same or different
> names, depending on what behavior you want.
Please attach an example file.
Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the document.
Dear Bug Submitter,
This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!
Dear Bug Submitter,
Please read this message in its entirety before proceeding.
Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):
a) Provide details of your system including your operating
system and the latest version of LibreOffice that you have
confirmed the bug to be present
b) Provide easy to reproduce steps – the simpler the better
c) Provide any test case(s) which will help us confirm the problem
d) Provide screenshots of the problem if you think it might help
e) Read all comments and provide any requested information
Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:
a) respond via email
b) update the version field in the bug or any of the other details
on the top section of our bug tracker