1842685 - Printing Editable Forms

Status: RESOLVED FIXED

(GeckoView :: PDF Viewer, enhancement, P1)

Description

[Olivia Hall [:olivia]]

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

Comment 1

[Olivia Hall [:olivia]]

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

Comment 2

[Olivia Hall [:olivia]]

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.

Comment 3

[Calixte Denizet (:calixte)]

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.

Comment 4

[Calixte Denizet (:calixte)]

Attachment: Bug 1842685 - Use window.print when printing a pdf in Geckoview r=#geckoview-reviewers

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/805b1cd53210
Use window.print when printing a pdf in Geckoview r=geckoview-reviewers,ohall

Comment 6

[Narcis Beleuzu [:NarcisB]]

Backed out for PDF related junit failures

Backout link: https://hg.mozilla.org/integration/autoland/rev/0e9cb62ee3805ddb89441d8ba79a60974941a78c
Log link: https://treeherder.mozilla.org/logviewer?job_id=424335810&repo=autoland&lineNumber=11183

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8ccad8ba7c8f
Use window.print when printing a pdf in Geckoview r=geckoview-reviewers,ohall

Comment 8

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/8ccad8ba7c8f

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

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