Repeated fields are saved incorrectly into the pdf

[Andrew5445]

Attach (recommended) or Link to PDF file here:

Configuration:

• Web browser and its version: Firefox 102.0
• Operating system and its version: macOS 12.0.1
• PDF.js version: v2.14.305
• Is a browser extension: No

Steps to reproduce the problem:

1. Download the attached file created-by-pdfjs.pdf
2. Open it in either Chrome or Adobe Acrobat
3. Click on the first or second field

What is the expected behavior? (add screenshot)
The pdf has been filled in Firefox PDF viewer and contains two fields with a same name and value "abc". The field values should not disappear after clicking on the values. But in the attached pdf it does - VIDEO from Chrome browser

I should add that it works in the Firefox browser correctly, but this should work everywhere since it is a supported feature.

What went wrong? (add screenshot)
When you have two or more fields with the same name, each value is saved into the widget annotation - "/Widget /Type /Annot..." . . On the left you can see how the two fields with the name "name" are saved into the pdf, on the right in comparison how one field is saved into the pdf. The fields are supposed to be saved like on the right.

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

[calixteman]

When the data are saved a V entry is created for each of the both fields (with the same value: "abc") when only one should be created in the parent.

[Andrew5445]

@calixteman yes, do you have the same problem?

[donarus]

Hi there, I've just realized that we have the same issue. @calixteman From your response, it seems like this is unexpected behavior and this issue should be considered as a bug in PDF.js. Am i right?

Is it somehow possible to workaround this issue?

[calixteman]

Yes it's a bug in pdf.js, my comment above was an explanation of what the problem is exactly.
I'll try to fix this issue asap but I can't promise anything.
About a workaround... I don't think there is one unfortunately.

[Snuffleupagus]

Did PR #19054 perhaps fix this issue as well?

[calixteman]

Fixed by #19054.