Closed Bug 1842685 Opened 8 months ago Closed 7 months ago

Printing Editable Forms

Categories

(GeckoView :: PDF Viewer, enhancement, P1)

Firefox 117
All
Android
enhancement

Tracking

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

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

People

(Reporter: olivia, Assigned: calixte)

References

(Blocks 1 open bug)

Details

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

Attachments

(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.

STR:

  • 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
Status: NEW → ASSIGNED
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:
https://github.com/mozilla/pdf.js/pull/16163
and I just update the patch to release pdf.js in m-c:
https://bugzilla.mozilla.org/show_bug.cgi?id=1845792#c4

I'm writing the patch for GeckoSession.java.
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 cdenizet@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/805b1cd53210
Use window.print when printing a pdf in Geckoview r=geckoview-reviewers,ohall
Pushed by cdenizet@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8ccad8ba7c8f
Use window.print when printing a pdf in Geckoview r=geckoview-reviewers,ohall
Status: ASSIGNED → RESOLVED
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.