1659819 - Add API for saving current page as a PDF

Status: RESOLVED FIXED

(GeckoView :: PDF Viewer, enhancement, P1)

Description

[James Willcox (:snorp) ([e-mail]) (he/him)]

Fennec had this, and we've had some complaints that this is missing in Fenix.

Comment 1

[James Willcox (:snorp) ([e-mail]) (he/him)]

It looks like we can use nsIWebBrowserPrint for this, probably ripping off a bunch of stuff from DownloadCore.jsm.

https://searchfox.org/mozilla-esr68/source/toolkit/components/downloads/DownloadCore.jsm#2792

Comment 2

[Jonathan Watt [:jwatt]]

You shouldn't use nsIWebBrowserPrint directly. And that DownloadCore code should be gone now. Something like this is probably more what you need:

https://searchfox.org/mozilla-central/rev/9fab6c0021ed9b103a70bf5c296b45949a2950bc/browser/components/extensions/parent/ext-tabs.js#1279

Comment 3

[Jonathan Watt [:jwatt]]

I should say, the linkedBrowser thing there is just a wrapper around FrameLoader.print().

Comment 4

[Robin Bankhead]

I'm following the github ticket that waits on this issue and wonder if devs could clarify something for us:

https://developer.android.com/training/printing/custom-docs

It seems to say (unless they are just making an example there, that's the part I'm unsure of) that to make a print job for Android you need to generate a PDF file.

Is that correct? Because if so, fulfilling this task would be 99.9% towards satisfying the need for a general-purpose printing capability. That would add a great deal of priority and much wider audience to this bug.

Comment 5

[Jonathan Almeida [:jonalmeida]]

ohall and I have written up a design doc for the GeckoView API for comment from the rest of the team: https://docs.google.com/document/d/1pxrQu8F3-nGHYsX-yBYjIECHgvYOGqDDuTz_XZl9KjE/edit

Comment 6

[Robin Bankhead]

Very pleased to see this gathering some momentum.

Since it is not alluded to in the design document, can I ask whether consideration is given in this effort to the additional goal of supporting in-browser print function?

I appreciate that goal is out-of-scope here, and this work will in any case give users an indirect route to printing pages.

However, native print capability (and support of window.print()) is also a sought-after objective, and by my understanding, having PDF output will put it within reach. I'm just hoping that this work is undertaken with that in mind, so that the design does not unintentionally throw up any roadblocks to that additional goal.

Comment 7

[Jonathan Almeida [:jonalmeida]]

Thank you for reviewing the doc! Native print functionality is very different on Android. In a future iteration, we might pursue a similar solution as Fennec by delegating the actual printing to a provider that embedders (like Fenix) can connect to, for example Google Cloud Print.

Comment 8

[Robin Bankhead]

John, thanks for replying. My understanding (based on the Android docs linked in my earlier comment) was that generating a PDF from the rendered page was the "hard part" in the case of native printing, as Android's own API takes it from there. Is that not the case? What is the greater challenge involved?

Did Fennec rely Google Cloud Print for printing? Is that service somehow instrumental in facilitating "normal" printing to e.g. a local CUPS printer? I thought it simply used the native print service, or so it appeared.

Sorry for OT questioning, the PDF effort in itself is hugely encouraging obviously, but printing is a killer feature for many users yet to date there's been zero developer input on the Fenix ticket (#10217), it remains in limbo and we'd welcome any further detail to help us understand the scale/scope of what's involved in that effort. Some commentary over there would be very welcome.

Comment 9

[Teoh Han Hui]

for example Google Cloud Print

Which has long been discontinued. It's been over a year now.

Comment 10

[Jonathan Almeida [:jonalmeida]]

(In reply to Robin Bankhead from comment #8)

John, thanks for replying. My understanding (based on the Android docs linked in my earlier comment) was that generating a PDF from the rendered page was the "hard part" in the case of native printing, as Android's own API takes it from there. Is that not the case? What is the greater challenge involved?

We're quite fortunate that we can leverage the existing work that platform/desktop have done in previous releases to make Save to PDF that "just works" for GeckoView too. The hard part now is creating a GeckoView API.

Did Fennec rely Google Cloud Print for printing? Is that service somehow instrumental in facilitating "normal" printing to e.g. a local CUPS printer? I thought it simply used the native print service, or so it appeared.

Sorry for OT questioning, the PDF effort in itself is hugely encouraging obviously, but printing is a killer feature for many users yet to date there's been zero developer input on the Fenix ticket (#10217), it remains in limbo and we'd welcome any further detail to help us understand the scale/scope of what's involved in that effort. Some commentary over there would be very welcome.

The "printing" side will probably be part of the Fenix team's product direction. I used the example of Google Cloud Print as a solution which Fennec took, but the integration to a printing service is up to that product team's requirements and bandwidth. This bug is to unblock that team so they can start considering options - I've added to the needs:gv on that linked issue to make it clear - thanks for bringing that up.

Comment 11

[Robin Bankhead]

Thanks, that makes things a little clearer (it's not always clear to us laypersons where responsibilities fall between GeckoView and Fenix the "product" and there are tickets in both trackers for both these issues).

Can I then please trouble you or anyone so empowered to complete the matrix of dependencies:

GeckoView bug for window.print()
https://bugzilla.mozilla.org/show_bug.cgi?id=1659818
should depend on this bug.

The needs:gv tag added to the additional Fenix issues:

Save as PDF Option
https://github.com/mozilla-mobile/fenix/issues/3709

Support window.print()
https://github.com/mozilla-mobile/fenix/issues/13214

Comment 12

[Chris Peterson [:cpeterson]]

Fenix would like this PDF API in GV 100 or 101 so they can implement Save as PDF in https://mozilla-hub.atlassian.net/browse/FNXV2-19887.

Comment 13

[Chris Peterson [:cpeterson]]

Saving a PDF to a stream (bug 1760836) probably won't be ready in 100, so I'll bump this bug to GV 101 or later.

Comment 14

[Chris Peterson [:cpeterson]]

Assigning this bug to Olivia because she's working on the PDF API.

Comment 15

[maksim]

Just a friendly reminder. I hope this is not getting forgotten.
Maybe I'm wrong but i haven't noticed any progress in a while.

Comment 16

[Olivia Hall [:olivia]]

(In reply to maksim from comment #15)

Just a friendly reminder. I hope this is not getting forgotten.
Maybe I'm wrong but i haven't noticed any progress in a while.

Hey, thanks for the reminder. Implementation is currently underway. Some things have changed from the original design document, so progress is moving a bit slower than expected. So far, it looks like the geckoview part will be ready by nightly 102.

Comment 17

[Olivia Hall [:olivia]]

Attachment: Bug 1659819 - GeckoView Save to PDF API

Adds a GeckoView save to PDF API that can be used to save the current session’s page content to a PDF.
The API returns a Java InputStream that can be used by the consumer to process the PDF.

Comment 18

[Chris Peterson [:cpeterson]]

No need to land this new GV API in 102. Nightly 102's soft code freeze starts tomorrow and Fenix isn't calling the new API yet:

https://mozilla-hub.atlassian.net/browse/FNXV2-19887

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fda1bbc3a74a
GeckoView Save to PDF API r=nika,agi,geckoview-reviewers,jonalmeida,emilio

Comment 20

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/fda1bbc3a74a