1618553 - pdf viewer should not fire the load event until it's ready for printing

Status: NEW

(Firefox :: PDF Viewer, defect, P1)

Description

[Boris Zbarsky [:bzbarsky]]

Apparently this is something people commonly do: create an iframe pointing to a pdf, and in its load handler try to print. See bug 911444 comment 87 and some of the preceding comments.

The problem is that we currently fire the load event before pageViewsReady becomes true, because Gecko has no idea that's going on behind the scenes and thinks the pageload is done. Can we delay it until it's true? I can expose platform APIs here if needed, but someone who actually knows the PDF viewer should handle that side.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I put a testcase at http://web.mit.edu/bzbarsky/www/testcases/pdf-printing/print-from-onload.html

Comment 2

[dotnetCarpenter]

Hrm. As I said in https://bugzilla.mozilla.org/show_bug.cgi?id=911444#c70 printing from a hidden iframe has been the defacto way of printing a PDF since I became a webdeveloper around 2001. So yes people commonly do this. It was not until PDF.js got embedded in Firefox that this approach had any issue. It still works in all other browsers and it used to work in Firefox.

I will follow this issue.

Comment 3

[Brendan Dahl [:bdahl]]

One of our contributors has proposed a solution that would trigger a method notifyPagesLoaded in PdfStreamConverter.jsm. From that method we could then continue printing. Alternatively, we could dispatch an event before beforeprint that is cancellable (or make beforeprint cancellable for pdf.js), then pdf.js would handle retriggering window.print().

bz,
How would you like to handle this on the platform side?

Comment 4

[Boris Zbarsky [:bzbarsky]]

For this specific bug, I think the best thing would be to not fire the load event until we're ready to print, because it's possible that the parent page will want to show some sort of UI at that point too.

On the platform side that probably means adding a way to block the load event firing and then unblock it. As in, ChromeOnly API for Document::BlockOnload() and Document::UnblockOnload. Or the PDF code could just add a dummy request to the loadgroup itself, I guess, but exposing the Document APIs seems safer/saner.

Would that be workable on the pdf.js end?

We could try to make beforeprint cancelale or add another pdf-js-specific event, but I'd rather have less platform-side special-casing here....

Comment 5

[Brendan Dahl [:bdahl]]

Blocking the load event seems reasonable on the pdf.js side. I'm bit worried that could mess with how the viewer is loaded, but I don't think we really depend on the load event for anything (unless other things are indirectly tied to it).

Comment 6

[Release mgmt bot [:sylvestre / :calixte / :marco for bugbug]]

The priority flag is not set for this bug.
:bdahl, could you have a look please?

For more information, please visit auto_nag documentation.