ff internal pdf viewer: flattened input fields still editable
Categories
(Firefox :: PDF Viewer, defect)
Tracking
()
People
(Reporter: thomas.kubatta, Unassigned)
Details
(Keywords: enterprise)
Attachments
(4 files)
Screenshot 2025-10-16 101550.jpg
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0
Steps to reproduce:
viewing a pdf with the internal pdf viewer of firefox.
the pdf had input-/acroformfields, that have been flattened (with itext).
Actual results:
some inputfields are still editable.
some, not all, there must be certain, different metadata in the internal pdf structure relating this fields
this happens not in adobe viewer, chrome, or any other viewers, everything works fine. this is definitly a ff internal pdf viewer issue.
Expected results:
like in adobe or chrome or any other viewers the input fields should be correctly viewed by the ff viewer as not editable
|
||
Comment 1•7 months ago
|
||
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.
|
Reporter | |
Comment 2•7 months ago
|
||
Unfortunately the priority is at least S2.
This is a very high major business impact and critical security issue, users are now able to manipulate important contractual documents
our company can't recommend using FF anymore (> 1000 users), worse, we can't forbid.
|
||
Updated•7 months ago
|
|
||
Comment 3•7 months ago
•
|
||
Without a PDF it's pretty impossible to debug.
So you must share such a pdf with us: we can make this bug confidential which means that only mozilla people will be able to see it or you can send it to me on my pro email.
Ideally, only if it's possible, having a public pdf would be better.
|
|
Reporter | |
Comment 4•7 months ago
|
||
|
|
Reporter | |
Comment 5•7 months ago
|
||
Hi,
i created a "stripped" example pdf file without confidental information, but still isolates the problem --> see attached ff_internal_pdfviewer_bug.pdf.
compare opening this file with ff pdfviewer and adobe, chrome or any other pdf viewers.
Further information:
It seems to be very special, the original was a template üdf with acroform input fields, that have been filled and changed programatically with itext8.
Finally it was rendered/fixed/ flattened with itext8.
As result the input fields still remain in ff internal pdf viewer, but as mentioned not in others viewers.
|
|
||
Comment 6•7 months ago
|
||
The pdf is corrupted: it contains some form annotations but it has no AcroForm dict in the root.
Then each fields have a parent entry where the Kids entry is wrong (it should contain at least a field) and they don't have a T entry.
In Acrobat the T entry is absolutely required but it's ok in Chrome or Edge.
In Edge, the missing AcroForm avoid to display the fields.
The attached test case is fine in Chrome when it's passed through qpdf.
That said the pdf hasn't the "Filling of form fields" permission which is very likely why the fields aren't shown in Chrome.
In about:config, you can set pdfjs.enablePermissions to true and it should work as expected.
In policies.json, you can enable permissions:
https://searchfox.org/firefox-main/rev/d87eb30d610a3032111f9ee47441b53927de63d3/browser/components/enterprisepolicies/schemas/policies-schema.json#1115-1125
and it should fix your issue for your company.
In the case where it isn't fixed by this policy change, then you should provide a pdf without having the permission "Filling of form fields" enabled and I'll try to figure out why our competitors don't show the form elements.
If you want to keep the policy as it is now for you, you'll have to update your itext8 code to correctly clean the pdf.
|
|
Reporter | |
Comment 7•7 months ago
|
||
Thank you for the information and your efforts.
First of all, I am a friend and supporter of the free internet and also a donor to Mozilla.
But I have to be critical in order to achieve satisfactory results.
I have attached the file without password protection in the attachment. sorry, I should have thought of that. You can now see that the file is displayed correctly in Acrobat, Chrome, and all other PDF viewers in the world.
I am aware that PDFs can be quite wild, but it is hard to accept that the file is corrupt. The company I work for has been creating these PDFs for years with Adobe, and we're not doing anything illegal with itext.
The PDFs have also been used and displayed on the public internet for years. So it's not a solution for us if Firefox settings have to be changed on PCs on the intranet. We can only put a block and a notice on the website telling people not to use Firefox anymore. We want to prevent that, also in the interests of Mozilla Firefox.
|
|
Reporter | |
Comment 8•7 months ago
|
||
|
|
||
Comment 9•7 months ago
|
||
(In reply to thomas.kubatta from comment #7)
First of all, I am a friend and supporter of the free internet and also a donor to Mozilla.
Thank you.
I am aware that PDFs can be quite wild, but it is hard to accept that the file is corrupt. The company I work for has been creating these PDFs for years with Adobe, and we're not doing anything illegal with itext.
When I said that the pdf is corrupted, I just meant that it doesn't fulfill the pdf specifications (https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf), nothing else.
The PDFs have also been used and displayed on the public internet for years. So it's not a solution for us if Firefox settings have to be changed on PCs on the intranet. We can only put a block and a notice on the website telling people not to use Firefox anymore. We want to prevent that, also in the interests of Mozilla Firefox.
With or without password, we display the form fields because by default we don't fulfill the pdf permissions.
Because it's an issue in your company, I mentioned that it was possible to change this behavior by changing a policy. I'm not an expert about that but :mkaply could help you if you need.
|
||
Comment 10•7 months ago
|
||
Do y'all use enterprise policy or configure Firefox in any way?
|
|
||
Comment 11•7 months ago
|
||
Thomas, just to clarify: the fields in the PDF are not shown in other PDF software because the "Filling of form fields" permission is disabled, and Firefox ignores this permission. It is not because the fields are flattened.
Can you try enabling this permission in the PDF, then open it in another software and check if it still doesn't allow filling the fields? If yes, attach the PDF here.
|
|
||
Comment 12•7 months ago
|
||
Just to reiterate how to do this (was kind of lost in Calixte's post)
Type about:config in the URL bar
Search on
pdfjs.enablePermissions
Double click it to set it to true.
|
|
Reporter | |
Comment 13•7 months ago
|
||
Thank you @all
... and Shame on me!
I attached a wrong file "ff_internal_pdfviewer_bug_decrypted.pdf". This file still needs a password.
Sorry, please see the new file ff_internal_pdfviewer_bug_REALLY_decrypted.pdf
and yes, if i set pdfjs.enablePermissions to true, the fields are no longer editable.
What i do not understand:
In the original file there are many more input fields.
after filling the fieds with itext i finally do a
pdfAcroForm.flattenFields(); // there are also optional methods for partial flattening, but we use this and it works fine since years
after this command must be flattened and thbey are. it should not anymore be possible to edit any fields in the document, and i see when openening the file also in acrobat adobe pro version, that there aren't any unflattened fields, otherwise i should see and may edit them, too.
Only in the ff viewer some fields are still editable. It seems there still remain any fragments/informations in the pdf, that are interpreted in another way by the ff viewer, than in acrobat pro, which leads to show them still as editable.
Maybe iText8.0.5 does not work perfectly, maybe our employee who creates the pdfs does something wrong or experimental, but he uses the adobe pro version as usual.
Everything works fine in this process since years, but i am not sure, if this happens in ff since years and nobody has realized is yet or there was a significant change on your site.
Anyway i will try to find a way making this pdf clean of any formfield fragments, maybe a migration to itext9, don't know now, if i find a way i will let you know in this ticket...
regards
thomas
|
|
Reporter | |
Comment 14•7 months ago
|
||
|
|
Reporter | |
Comment 15•7 months ago
|
||
EDIT:
now, it gets spooky....
sorry, in the new file ff_internal_pdfviewer_bug_REALLY_decrypted.pdf, i described before, there aren't any ediable fields in Acrobat.
But just now, i see, that they arte also not editable in ff, too.
What happened ?
I only opened the pdf in acrobat, removed security settings by entering the password, then save (without pw)
while saving , it seems something must have been repaired in the pdf, too.
this is really weird and yes, meanwhile pdfs really drive me crazy...
but how to get the flattened pdf without password and editable fields?
i just printed the document again with the java program and disabled temporarely setting a password with iText in order to get the same result as before , just only wihtout pw.
and now opening the file in acrobat i see, the fields are not flattened
Yes it's complicated, but at this point it's no longer an impact with the ff viewer.
thank you for your time, efforts and sorry, but pdfs are really something fragile for pdf experts only ...
|
|
Reporter | |
Updated•7 months ago
|
Description
•