PDF form controls issues in latest versions

[GopiUC]

Hi,

1.CheckBox saved as unchecked after edit.
2. Selected radio button is not selected in edit mode.

1. In few Checkboxes checked and saved the PDF form successfully.

In our functionality, we can edit the PDF form,
Check other checkboxes, and save it again. However, the form data sends value as 'undefined ' for previously checked boxes.
Only newly selected check boxes are saved as 'true' in the pdf, while those already checked are unchecked.

*This functionality working fine in Version 16.2.8.

2. And another issue we faced is, From version 18.1.1 - In Edit mode Selected radio button is seems like unselected, but in view mode it displayed correctly what we fetched from API. Till 18.1.0 it works fine. So, now we roll back to 18.1.0.

Both functionalities are not correctly working in current versions. Please check and advise how can we fix this issues.
Checkbox issue is very crucial for us.

Thank you for your time,
GopiVignesh

[stephanrauh]

I wonder if this is a duplicate of #2052?

[stephanrauh]

I can't reproduce your bug on https://pdfviewer.net/extended-pdf-viewer/forms. Maybe it has something to do with your particular form. However, I wonder why you fetch the form data using pdfService.getFormData()? That's a low-level API giving you the raw data. Is there a reason why you don't use the data passed in $event?

[GopiUC]

Thank you for the response, I used $event data to update formdata. Now chcekBox value updated correctly.

[GopiUC]

For Second Point, In that form Radio button used like checkbox. Please check that point too and refer first message

"2. And another issue we faced is, From version 18.1.1 - In Edit mode Selected radio button is seems like unselected, but in view mode it displayed correctly what we fetched from API. Till 18.1.0 it works fine. So, now we roll back to 18.1.0."

"For the second point, 'edit mode' and 'view mode' refer to the 'FormFlattening' flag 'false' and 'true' respectively. 'FormFlattening' is the property of pdfStamper. That FormFlattening flag handled in GetAPI of PDF form.
That flag was used to determine whether the form should be used for editing or viewing only.

Please refer above img, we used radio button like this."

[stephanrauh]

Sorry for responding so sluggishly! I've tried to find out what I changed between version 18.1.0 and 18.1.1. I don't see many form-related changes. Maybe this commit causes trouble: stephanrauh/pdf.js@a6163a2.

You've sent me only one screenshot, so I can only guess whether that's the correct or the faulty state. When you say "the radio button seems like unselected", is it only a display problem, or is it disabled in the DOM, too? You can check this using the "elements" tool of your browser's developer tools. I also wonder if you PDF form is a traditional AcroForm or an XFA form.

[GopiUC]

Thanks for your response and efforts in investigating the issue.

Confirming that the radio button appears disabled both visually and in the DOM when we get form for update. I've checked using browser's developer tools. In version 18.1.1

Regarding the PDF form type, it's a traditional AcroForm only.

In this screenshot that radio button was selected and saved. When get form for edit It seems like unselected, in DOM too.

But I open that saved form in WPS office it seems selected image attached below.