1770750 - Firefox is not saving edits on a pdf file.

Status: RESOLVED FIXED

(Firefox :: PDF Viewer, defect, P1)

Description

[dogunbound5]

Attachment: ferpa-2020 (4)-1.pdf

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

Edit a pdf document in firefox, and hit save or download.

Actual results:

Changes are not persistent.

Expected results:

Hitting save/download should change the file. It works fine in chrome, so I know it's a firefox issue, not a pdf issue.

Comment 1

[dogunbound5]

It may be something with the specific pdf file + firefox.

Comment 2

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Firefox::PDF Viewer' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Calixte Denizet (:calixte)]

With Firefox 100 on Windows 11, I entered something in the first field, saved it in using the dl button and opened the resulting pdf: the data are here.
:marco, are you able to reproduce on linux ?

Comment 4

[Marco Castelluccio [:marco]]

I can reproduce when touching the second field and opening the PDF with Evince.
If you open the saved PDF in Firefox, the correct value is shown.
If you open the saved PDF in Master PDF Editor, the correct value is shown.
If you open the saved PDF in Evince, the value "Click Here to Select One" is shown instead of the correct one.

dogunbound5, is this what you are seeing too?
This might be a bug in Evince. Calixte, could you try with Adobe Reader?

Comment 5

[Calixte Denizet (:calixte)]

The second field has the value "Main" and is rendering like this in Firefox and Edge.
Without touching anything, if I download it from Firefox or Edge and open it in Acrobat, the select always shows "Click Here to Select One".

Comment 6

[Calixte Denizet (:calixte)]

The Choice widget allow only the selection of one element (Ff = 131072 === 2^17) and has an entry I with a value of [0] which should be used only when multiselect is enabled, from the pdf specs (about I entry):

For choice fields that allow
multiple selection (MultiSelect flag set), an array of integers, sorted in ascending
order, representing the zero-based indices in the Opt array of the currently
selected option items. This entry shall be used when two or more elements in the
Opt array have different names but the same export value or when the value of
the choice field is an array. This entry should not be used for choice fields that do
not allow multiple selection. If the items identified by this entry differ from those in
the V entry of the field dictionary (see discussion following this Table), the V entry
shall be used.

And as far as I can tell Acrobat is using the I value when it shouldn't, because when I remove the entry from the annotation dictionary the rendering is correct in Acrobat.
So from my point of view, there are 2 issues here:

• the pdf generator wrongly added a I entry;
• Acrobat and Okular (Windows version) are using this entry to choose the selected value.

On the Firefox' side, we can "fix" a saved pdf when it has been modified by the user in removing the I entry, but unfortunately we cannot do better.

Comment 7

[Calixte Denizet (:calixte)]

Another possibility is to give to I the correct value when saving.

Comment 8

[Marco Castelluccio [:marco]]

No longer need info from the reporter, we are able to reproduce.

Comment 9

[Calixte Denizet (:calixte)]

:Snuffleupagus, usually what is the precedence between pdf specifications and the implementation in Acrobat ?

Comment 10

[Jonas Jenwald [:Snuffleupagus]]

(In reply to Calixte Denizet (:calixte) from comment #9)

:Snuffleupagus, usually what is the precedence between pdf specifications and the implementation in Acrobat ?

The PDF specification is notoriously incomplete/underspecified in some areas, especially regarding Annotations, when comparing with the actual behaviour observed in Adobe Reader.
We already have a bunch of code where we basically try to mimic the behaviour in Adobe Reader, try searching for "adobe" in https://github.com/mozilla/pdf.js/blob/master/src/core/annotation.js and https://github.com/mozilla/pdf.js/blob/master/src/display/annotation_layer.js

So, this is probably yet another case where we have to ignore the exact wording of the PDF specification in order to improve our compatibility with other PDF viewers.

Comment 11

[BMO Automation]

Attachment: [mozilla/pdf.js] [Annotation] For choice widget, use the I entry instead of the V one (bug 1770750) (#16031)