Closed Bug 1842685 Opened 8 months ago Closed 7 months ago

Printing Editable Forms


(GeckoView :: PDF Viewer, enhancement, P1)

Firefox 117


(firefox115 unaffected, firefox116 wontfix, firefox117 wontfix, firefox118 fixed)

118 Branch
Tracking Status
firefox115 --- unaffected
firefox116 --- wontfix
firefox117 --- wontfix
firefox118 --- fixed


(Reporter: olivia, Assigned: calixte)


(Blocks 1 open bug)


(Whiteboard: [fxdroid][foundation][geckoview:m118])


(1 file)

Printing from the menu is currently behind a nightly flag (bug 1836780 and the flag will be removed in bug 1840471).

When printing from a PDF form, the original PDF is printed, not the PDF with the form changes.


  • Go to a PDF that has form fields
  • Edit one of the form fields
  • Print from the three dot menu or share menu on Fenix
  • The original form will be printed, not any of the edited changes
Whiteboard: [fxdroid][foundation]
Severity: -- → S3
Priority: -- → P2

When using the Android menu "Save to PDF", the edited form fields values are correctly saved. Printing is using the same API saveAsPdfByBrowsingContext to get the PDF from the PDF viewer. So, it looks like the print spooler is correctly receiving the edited PDF from the viewer.

Also checked by sending an edited PDF file directly to the PrintDocumentAdapter, which did not show a print preview of the file edits. When saving the print preview PDF, the edits do appear in the saved document, but in an incorrect location.

This could mean there an issue in the PrintDocumentAdapeter or else something specific to printing that does not happen when "Saving as a PDF".

Hi Calixte,

Do you think for editable PDF forms, should GeckoView be using a different PDF file specially setup for printing rather than the PDF file itself? I read some of the comments in the patch on bug 1810111. It made me wonder if some callbacks needed to happen to generate static text in the form field or something for printing editable PDFs. Any advice or tips about PDF forms?

I haven't seen anything in the PrintDocumentAdapter to adjust yet, but that is another possibility too.

Some more info, I noticed the Google file viewer had trouble printing PDFs with edited fields on Android, but the Adobe app seemed to print okay on Android. I also saw in the Adobe app that I had to touch the frame for the saved edits to render, which also made me wonder if something needed to pre-process the text when printing forms.

Flags: needinfo?(cdenizet)
Assignee: nobody → cdenizet
Flags: needinfo?(cdenizet)
Priority: P2 → P1

For now we'll just plug the printing in pdf.js on window.print and everything will work as on desktop:
and I just update the patch to release pdf.js in m-c:

I'm writing the patch for
We can do something smarter in order to avoid to uselessly use window.print stuff which is likely resource consuming.
For example, pdfs with no forms don't need to be printed: we can just send them as they're to the print app.
I'll do a follow-up soon.

Depends on: 1845792
Whiteboard: [fxdroid][foundation] → [fxdroid][foundation][geckoview:m118]
Pushed by
Use window.print when printing a pdf in Geckoview r=geckoview-reviewers,ohall
Pushed by
Use window.print when printing a pdf in Geckoview r=geckoview-reviewers,ohall
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → 118 Branch

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Flags: needinfo?(cdenizet)
You need to log in before you can comment on or make changes to this bug.