Found in

• 115.0b6 (20230613195413)

Affected versions

• 114.0
• 116.a1

Tested platforms

• Affected platforms: Win10, Win7.
• Unaffected platforms: -

Steps to reproduce

1. Open link https://www.irs.gov/pub/irs-pdf/f1040.pdf
2. Check all checkboxes from Filing status section.
3. Click on Save button next to printing.
4. Save the pdf.
5. Open saved pdf on PC. Check the checkboxes.

Expected result

• On saved pdf all checkboxes should be checked.

Actual result

• Only the last selected checkbox is displayed as checked (see screenshot attached).

Additional notes

• I was able to reproduce it on the 114.0 release also.
• Will look for a regression.
• Issue seems to reproduce only when using the Save option. Issue is not reproducing if using the print option.

I can't reproduce in Nightly on Windows 11.

This pdf contains the form in two formats: Acroform and XFA.
Since Acroform support is a way better than XFA one, we decided to render Acroform.
By design, the Acroform doesn't specify that the checkboxes are mutually exclusive.
We could explore the XFA to try to figure out something but in this particular case, even if it's possible to define a group of buttons as a radio group, by design, the mutually exclusive behavior is implemented with some JS callbacks.
To conclude, this pdf is poorly designed.
In considering the items associated to the checkboxes, I suppose it's obvious that they're mutually exclusive.

Ah I can actually reproduce when opening the PDF saved from Firefox in Adobe Acrobat.

In Adobe Acrobat, you are forced to only select one box at a time.

I managed to read this pdf in Acrobat without XFA (in disabling JS) and the checkboxes behave correctly.
In playing with the T field, I noticed that if I change the name c1_0[0] to X1_0[0] then the button is excluded from the group.
My guess is that when we've have some terminal nodes in the Field tree with an index then it means that those nodes belong to the same group.
Anyway it isn't a regression and I think I've a fix.

The patch landed in nightly and beta is affected.
:calixte, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox115 to wontfix.

For more information, please visit BugBot documentation.

This bug is likely pretty rare, hence it can wait for the next cycle.

Reproduced the issue with Firefox 115.0b6 (2023-06-15) on Win 10.
The issue is verified fixed with Firefox 117.0a1 (20230726093921) and Firefox 116.0 (20230724170120) on MacOS 12, Win 10 and Ubuntu 22.

The workaround wasn 't good so the patch has been reverted.
We'd need to either render the xfa or extract some information from the xfa itself when rendering the acroform.