dear developpers,

i know it is a old issue but im still having problems when using this feature, the good news is: i have a stable workaround.

CASE: (works on chrome, but fails on firefox):

  <iframe id='x1' src='/path/to.pdf'></iframe>

  <script>
    document.getElementById('x1').contentWindow.print(); 
    // dialog window pop ups on chrome, not firefox.
  </script>

WORKAROUND:

Build the IFRAME from a ajax call (instead of adding the "<iframe>.." directly into our html).

  <div id='pdf'>...</div>

  <script>
  setTimeout(function(){ 
   $.ajax({ cache: false, type: 'post', url: 'some/path/to/buildIframe.php',                                         
      success: function(resp) {
         
         $('#pdf').html(resp);
          
         document.getElementById('x1').contentWindow.print();
      }
    });
  }, 100);
  </script>

on the server side, (using php as an example) :

<?php 
   // file: buildIframe.php

   // do your own implementation to respond the ajax request ...
   
   echo "<iframe id='x1' src='/path/to.pdf'></iframe>";
?>

(In reply to Christian Salazar from comment #60)

dear developpers,

i know it is a old issue but im still having problems when using this feature, the good news is: i have a stable workaround.

CASE: (works on chrome, but fails on firefox):

  <iframe id='x1' src='/path/to.pdf'></iframe>

  <script>
    document.getElementById('x1').contentWindow.print(); 
    // dialog window pop ups on chrome, not firefox.
  </script>

WORKAROUND:

Build the IFRAME from a ajax call (instead of adding the "<iframe>.." directly into our html).

  <div id='pdf'>...</div>

  <script>
  setTimeout(function(){ 
   $.ajax({ cache: false, type: 'post', url: 'some/path/to/buildIframe.php',                                         
      success: function(resp) {
         
         $('#pdf').html(resp);
          
         document.getElementById('x1').contentWindow.print();
      }
    });
  }, 100);
  </script>

on the server side, (using php as an example) :

<?php 
   // file: buildIframe.php

   // do your own implementation to respond the ajax request ...
   
   echo "<iframe id='x1' src='/path/to.pdf'></iframe>";
?>

im sorry, i forget to metion this:

wrap this call:

document.getElementById('x1').contentWindow.print();

with:

setTimeout(function(){ ... }, 10);

the "10" ms value is needed, when too large then it wont work..

This issue has reared it's ugly head once again. I have designed a beautifully elegant solution to printing reports in a web application that involves loading a pdf into a hidden iframe and printing from that. Wonderful works perfectly in Chrome and even in Edge. Alas, Firefox you wound me. I took to the internet sure I had done something wrong. Ney, an error from over 8 years ago plagues us. I guess this is just a wordy +1 post, but without these, I don't believe that this issue will be resolved. Thank you for your time.

Actually, the +1 posts will make it harder to resolve the issue, because they make it harder to find the technical discussion....

I should also note that the solution in comment 62 may not work so great for users who turn off the built-in PDF viewer in their browser.

Another year has gone by with no end in sight on a 6 1/2 year old, highly problematic bug. As has been stated many, many times, this is rather critical functionality that only Firefox has an issue with and has not prioritized fixing over the past 7 years, despite promises to the contrary. Like many others, I find myself in the unfortunate position of potentially having to explain to our clients that they will need to avoid Firefox in order to use our applications.

Just in case it wasn't clear, fixing this more or less requires a complete rewrite of the PDF viewer. And yes, it's been hard to prioritize that because for most consumers of the PDF viewer this is not the most pressing problem. I sympathize with the cases when it is, and I've been spending some time thinking about this, but I really haven't had much time to devote to this.

I will try to see if I can increase the visibility of this, though.

Actually, there might be ways to do this without a complete rewrite. So here's a specific question: if the print() call were implemented internally in terms of an async postMessage() to the pdf document that then triggers exactly the same codepath as clicking the "print" button in the iframe/window showing the PDF, would that address the use cases people have for this? (It still wouldn't work for users who disable the built-in PDF viewer, of course...)

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #66)

Actually, there might be ways to do this without a complete rewrite. So here's a specific question: if the print() call were implemented internally in terms of an async postMessage() to the pdf document that then triggers exactly the same codepath as printing the "print" button in the iframe/window showing the PDF, would that address the use cases people have for this? (It still wouldn't work for users who disable the built-in PDF viewer, of course...)

I thought the issue was strictly related to how the PDF viewer is embedded in firefox (resource://pdf.js)?
That means that the firefox pdf.js version will break pdf's (.print()) included in an iframe.

pdf.js works in all browsers and also in firefox if included by the web author (in contrast to the firefox browser).
However, that means that the user has to download pdf.js, even though it is bundled with the firefox browser...

Main focus appears to be, embed pdf.js in Firefox in a way that does NOT prevent calls to .print().

Embedding pdf.js in a semi-privileged document was a big mistake in the first place
https://github.com/mozilla/pdf.js/issues/10290#issuecomment-441236088

1. This bug is a regression - .print() worked in firefox before pdf.js was embedded.
2. This bug is a parity issue - .print() works in all other browsers but firefox.

I thought the issue was strictly related to how the PDF viewer is embedded in firefox (resource://pdf.js)?

Yes, but changing that is ... complicated, because the script actually needs some special privileges to do some of the things it's doing, as I understand.

pdf.js works in all browsers and also in firefox if included by the web author

My understanding (which could be wrong!) is that there are some functionality restrictions when used this way.

Main focus appears to be, embed pdf.js in Firefox in a way that does NOT prevent calls to .print().

There is no resourcing for that and won't be for the foreseeable future. Waiting on that resourcing is where we've been for how long now?

I would still appreciate answers to my specific question from comment 66. Just repeating that this is problem is not helpful; we all know it's a problem here.

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #66)

Actually, there might be ways to do this without a complete rewrite. So here's a specific question: if the print() call were implemented internally in terms of an async postMessage() to the pdf document that then triggers exactly the same codepath as printing the "print" button in the iframe/window showing the PDF, would that address the use cases people have for this? (It still wouldn't work for users who disable the built-in PDF viewer, of course...)

Yes, if I'm understanding, I believe that would work for my use case.

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #66)

Actually, there might be ways to do this without a complete rewrite. So here's a specific question: if the print() call were implemented internally in terms of an async postMessage() to the pdf document that then triggers exactly the same codepath as clicking the "print" button in the iframe/window showing the PDF, would that address the use cases people have for this? (It still wouldn't work for users who disable the built-in PDF viewer, of course...)

Yes. That should work. For my use-cases, using "the hidden iframe trick" as documented numerous places around the Internet, would suffice.
Here is one such example: https://www.sitepoint.com/load-pdf-iframe-call-print/

One more question for people. Is this just needed for iframes, or also for windows opened with window.open()? There are some security considerations that I'm trying to sort out and knowing that would help with what possible solutions are OK.

Imo, 99% cases is iframes. This is when you have Print button on the parent page and pdf preview in iframe. I also think that most of that is NOT cross-domain. No comments here mention window.open().

Personally I just want Print.js ( https://printjs.crabbly.com/ ) to work in Firefox like it does with Google. IIRC Print.js uses a hidden iframe.

Both would be useful, though I must admit that an iframe-only solution would solve my use case at this time.

The method is exposed only if the consumer has the same principal as the PDF
would have if it were not getting the PDF viewer treatment.

The method just calls the print() method in the PDF viewer window.

It's enough to expose this on OuterWindowProxy, not RemoteOuterWindowProxy,
because we ensure PDF documents end up in the process they would have been in
based on their pre-PDF-viewer principal.

This ensures we never have a RemoteWindowProxy from a page to a PDF viewer that
should have been same-origin with it.

This does not disclose any server-side information that would not ideally be
available anyway (if the PDF viewer were actually made same-origin with the
embedding page, say, when the PDF URL is same-origin).

In case of full-content-process security compromises, it doesn't look like the
APIs exposed to the PDF viewer allow anything that could not be done via other
methods available during such a compromise.

An iframe would also solve my use case

If people want to try builds with the above patches applied, they are available at:

• Win64: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/RrOIcl5jSlSImviJ85SKFA/runs/0/artifacts/public/build/target.zip
• Mac: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JVdOK5R3QIqw2H0Y9W34WA/runs/0/artifacts/public/build/target.dmg
• Linux64: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/G60jSb-5Rd6tvWRe4HJm8w/runs/0/artifacts/public/build/target.tar.bz2

Backed out 4 changesets (bug 911444) for Mochitest failures in dom/base/test/test_pdf_print.html. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=290261094&repo=autoland&lineNumber=3058

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&revision=d156bbaabbd5cb440fdea7721faa0fb954eb7739

Backout:
https://hg.mozilla.org/integration/autoland/rev/baa43fa6e5d2a55a993dd47594baf862dfb5893d

Looks like Android is not shipping the same PDF viewer? I need to double-check what the setup is there.

Yeah, we don't ship pdf.js on android.

Relanding with the test skipped on Android.

If people want to try builds with the above patches applied, they are available at:

I just tried it out and got "The page at resource://pdf.js says: Warning: The PDF is not fully loaded for printing", then the print dialog, which printed an empty page. For all the other browsers/plugins, we just have an addEventListener "load". If you've created a special print function, you'll need to tie it to the render promise to put it on parity with other browsers.

When I added a 10 second setTimeout, it came up with the print dialog before the "The PDF is not fully loaded for printing" message. It printed an empty page. Note, it took 604ms to download the PDF.

So, closer, but not quite there.

Jason, just so I understand, in your case the print function is not being called from a user clicking a button, but something more like this:

<iframe src="something.pdf" onload="this.contentWindow.print()"></iframe>

?

On the assumption that the answer to comment 88 is "yes", I filed bug 1618553.

That said, I'm surprised a 10s timeout was still not enough, unless this was a quite large PDF or something else is broken. A link to a testcase would be quite helpful.

That said, I'm surprised a 10s timeout was still not enough, unless this was a quite large PDF or something else is broken. A link to a testcase would be quite helpful.

That's why I mentioned that it only took 604ms to download the pdf. It's a single page, 55,211 bytes.

I'm unfortunately in the process of trying to rebuild an old project from 2002, that's how I landed in the "oh, it doesn't work for firefox, users were told to use anything but, unless they don't mind going to the new tab 150 times a day, hitting print, hitting ok, then closing the tab to go to the next set of orders/reports" and went on a hunt on how to fix it and found this post. I'll see if I can convince my supervisor to allow me to create a test page and put it live.

Jason, thanks, that would be very helpful in terms of figuring out what's going on with that case...

https://www.lenstock.com/FireFoxIFramePDFTest.aspx click the "details" button next to a garbage order, then below will be several different "print" buttons. The regular "print" button has how we currently handle firefox by window.open and after 3 seconds it tries to fire print() in a try catch block(that with the test version occasionally works now)

Thanks, that helps a lot. The issue is the "display:none" on the iframe; I filed bug 1618621 on that, and bug 1618626 to track this set of issues in general.

As a workaround, removing the display:none might help, but the timing of the load event is still wrong for your purposes, of course...

I removed the display:none and replaced it with the iframe being underneath the header with a z-index and low max height/widths. Didn't make any sort of difference, even to the 10 second timeout.

That's not live on https://www.lenstock.com/FireFoxIFramePDFTest.aspx, right? I still see the display:none iframe there...

Correct, not live. I changed it on my development machine to test it, didn't make a difference, so didn't push it out(that, and since the iframe is sitting on the masterpage, it would change for our live users using the rest of the site too and I'm not real hip on having to retest all the other browsers again).

Understood. I just haven't had luck so far reproducing the problem with a delay and without the display:none, so trying to figure out what other issue you might be running into...

https://hg.mozilla.org/mozilla-central/rev/c27d113d6f61
https://hg.mozilla.org/mozilla-central/rev/de114a360687
https://hg.mozilla.org/mozilla-central/rev/c0e52b90c522
https://hg.mozilla.org/mozilla-central/rev/e681c2a6d146

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #98)

Understood. I just haven't had luck so far reproducing the problem with a delay and without the display:none, so trying to figure out what other issue you might be running into...

I've gone ahead and updated it to use a different iframe that's an absolute position at the top under the header with a z-index with at least a little size. I can see it when I hide the header. Doesn't change the results. Note, the results I'm looking at is from the link provided 6 days ago for 75.0.0.7357.

Picked up todays nightly 75.0.0.7363 and have the same issue. If I use the non-delay print dialog, I get the print dialog then the not fully rendered message. If I use the delay print buttons, I get the not fully rendered message then the print dialog. In all cases it prints an empty sheet of paper(due to the not fully rendered bit).

Fun. The small size is the issue; I filed bug 1618955. Thank you very much for updating the page!

I think just doing a normal-sized absolutely positioned iframe with "visibility: hidden" should do the right thing, at least in my local testing. But obviously we should fix the small size thing too...

I've made this tests in Firefox Nightly / Linux / 75.0a1 (2020-02-28) (64-bit)

iframe with Big Size and visibility:hidden

Synchronous printing in the iframe.onload event

1. Warning: The PDF is not fully loaded
2. print dialog
3. Blank PDF

Asynchronous printing (with enough delay) in the iframe.onload event

1. print dialog
2. PDF OK :+1:

iframe with No Size

TL;DR In both cases I get a Blank PDF, but in the Asynchronous one the printing dialog appears first, and the warning message after

Synchronous printing in the iframe.onload event

1. Warning: The PDF is not fully loaded
2. print dialog
3. Blank PDF

Asynchronous printing (with enough delay) in the iframe.onload event

1. print dialog
2. Warning: The PDF is not fully loaded
3. Blank PDF

print with sufficient delay:

This bug is still present in Firefox 77. Only blank pages are printed.

The document is printed, but an error falls in the console "SecurityError: Permission denied to access property "document" on cross-origin object"

I've had a brief play with printing PDF in current release Firefox (version 80). My findings so far:

• An extra delay after the iframe element's load event is required. For a small PDF on my modern PC, 1000ms was enough but 100ms was not. I have not further information (yet) on what is a reliable delay.
• I'm pretty sure at least some of the PDF has to be visible for printing it to work. Hiding using CSS display or visibility, or via positioning the iframe outside of the visible page area using absolute positioning or transform, does not work ("The PDF is not fully loaded for printing" in most cases).
• Keeping the iframe visible and setting opacity: 0 works.
• After the call to the iframe window object's print() method, removing the iframe element immediately or even after a brief delay results in the printing dialog to hang indefinitely. However, things are fine if you hide the iframe using any of the previously-mentioned methods at this point.

I think I have a workable solution for my needs using the following:

1. Display the iframe in the visible area of the page with a reasonable size to ensure some of the PDF document other than its toolbar is visible. 80px high seems to be enough. I'm not sure there's any reason to restrict it to that though.
2. Make the iframe invisible to the user using opacity: 0.
3. Once the iframe's load event fires, wait for some interval (I'll need to experiment with larger PDFs to pin this down) before calling print() on the iframe's window object
4. After the print() call, set display: none on the iframe.

I created a gist of my working code: https://gist.github.com/timdown/cfacd32f6b5e439bb02aaf142343ce4c