Closed Bug 911444 Opened 10 years ago Closed 4 years ago

Error: Permission denied to access property 'print' on Firefox 23.0.1

Categories

(Firefox :: PDF Viewer, defect, P3)

Product:
Firefox
Component:
PDF Viewer
Version:
23 Branch
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 75
Tracking Flags:
Tracking Status
firefox75 --- fixed

People

(Reporter: justin.felisco, Assigned: bzbarsky)

References

Details

(Whiteboard: [pdfjs-c-integration])

Attachments

(4 files, 1 obsolete file)

Bug 911444 part 1. Factor out the "is pdf viewer" code so we can reuse it.
47 bytes, text/x-phabricator-request
Details | Review
Bug 911444 part 2. Allow sending an nsIPrincipal in a variant over IPC.
47 bytes, text/x-phabricator-request
Details | Review
Bug 911444 part 3. Store the principal a PDF viewer document would have had if the PDF viewer had not messed with the principal.
47 bytes, text/x-phabricator-request
Details | Review
Bug 911444 part 4. Expose a print method on PDF viewer windows.
47 bytes, text/x-phabricator-request
Details | Review 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.62 Safari/537.36

Steps to reproduce:

I used IFrame to display the PDF and the PDF is located on the same host. I'm using the PDF.js to display it, but I'm not using its print button. Instead I created a another print button to trigger the print feature. But I received error. But on other browsers it is working fine.


Actual results:

When I looked at on firebug, I received this message "Error: Permission denied to access property 'print'"


Expected results:

PDf inside the IFrame should be printed.
Priority: -- → P3
Can you provide a link that demonstrates this behaviour, or a code sample?
It should be pretty straightforward:

  <iframe src="some-same-origin.pdf"></iframe>
  <script>
    window.onload = function () {
      try {
        frames[0].print();
      } catch (e) {
        alert("Exception thrown: " + e);
      }
    }
  </script>

The issue is that the built-in PDF renderer creates a privileged document for the PDF, and the caller is not allowed to get the .print of a privileged window.  If, instead, we had used a full-page plug-in to render the PDF, the access here would be same-origin...

This is an issue in how pdf.js is hooked up to the docshell.
Component: General → PDF Viewer
Product: Core → Firefox
(In reply to Josh Matthews [:jdm] from comment #1)
> Can you provide a link that demonstrates this behaviour, or a code sample?

1st test:

var pdfFrame = document.getElementById('print_pdf_holder');
pdfFrame.focus();
pdfFrame.contentWindow.print();

1st test result:

Error: Permission denied to access property 'print'

2nd & 3rd test:

window.frames[0].focus();
window.frames[0].print();

window.frames.focus();
window.frames.print();

2nd test result:

Both shows Error: Permission denied to access property 'print'

But the in other browser, these test are working fine. Firefox 23.0.1 shows this error message.
(In reply to Boris Zbarsky [:bz] from comment #2)
> It should be pretty straightforward:
> 
>   <iframe src="some-same-origin.pdf"></iframe>
>   <script>
>     window.onload = function () {
>       try {
>         frames[0].print();
>       } catch (e) {
>         alert("Exception thrown: " + e);
>       }
>     }
>   </script>
> 
> The issue is that the built-in PDF renderer creates a privileged document
> for the PDF, and the caller is not allowed to get the .print of a privileged
> window.  If, instead, we had used a full-page plug-in to render the PDF, the
> access here would be same-origin...
> 
> This is an issue in how pdf.js is hooked up to the docshell.

I've tried your code snippet. But it returns Error: Permission denied to access property 'print'
> I've tried your code snippet. But it returns Error: Permission denied to access property
> 'print'

Yes, of course.  My code snippet was a reply to comment 1.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (20130901030218)
I encounter the following error using the code from Comment 2 on latest Nightly and Fx 23.0.1 :
Exception thrown: Error: Permission denied to access property 'print'

When using the code from Comment 3, the print dialog is opened, but a blank page is printed.

Marking this as NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [pdfjs-c-integration]
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0

Same issue here using a Mac.
Any update on the resolution...I am facing this too..
Is anyone looking at this? Is there a workaround. Please note that the embedded frame is on the same domain.
Wear over a month trying to give solution to this, today 2014-06-11 I have updated my Firefox to version 30.0 and the error still persists; Firefox is my preferred development for electronic invoice and my only alternative seems to be Chrome browser. Please someone who gave the solution?
Bobby, could we make this work somehow?  This is a case where effectively the fact that pdfjs is running with some weird principal is surprising users because that's not what a plugin document would be doing...  Can we make print() callable cross-origin in this one special case?  Ideally only if the actual origin we were loaded from is same-origin with the caller.
Flags: needinfo?(bobbyholley)
(In reply to Boris Zbarsky [:bz] from comment #11)
> Bobby, could we make this work somehow?  This is a case where effectively
> the fact that pdfjs is running with some weird principal is surprising users
> because that's not what a plugin document would be doing

I don't think we should make this work - it doesn't in other UAs, and the fact that we have a subframe here is an implementation detail. See my suggestion on bug 558184 comment 57 for a proposed architecture going forward - we should avoid exposing the existence of a descendant docshell entirely.
Flags: needinfo?(bobbyholley)
> it doesn't in other UAs

Does it not?

  <iframe src="test.pdf"></iframe>
  <input type="button" value="click me"
         onclick="frames[0].print();">
  </script>

works fine for me in Chrome at first glance as long as test.pdf is an actual PDF.  Make sure to run that over http://, not file://, though.

> and the fact that we have a subframe here is an implementation detail

No, the subframe is in the page markup.

> we should avoid exposing the existence of a descendant docshell entirely.

You're not allowed to do that for <iframe>.
Flags: needinfo?(bobbyholley)
Oh, I was confused about the different semantics of <iframe> and <embed>/<object>.

Reading the spec though, it looks like this should be fine - we should just do the normal plugin document thing for the iframe, and let the semantics in bug 558184#c57 work their magic in the <embed> inside the plugin document. Does that sound good?
Depends on: jsplugins-base
Flags: needinfo?(bobbyholley)
Yes, that would definitely fix this bug.
I think this is a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=647658 but don't want to mark it as such just in case I'm wrong.
It is, but dupping forward to here, since this bug has more info.
Hi,

This issue is reported an year ago, Is there any update on this?, please update the status of the issue. 

Thanks in advance
Sundar Racer
The status is that bug 558184 needs to be fixed first; see comment 14.  That should happen sometime in the next few months, hopefully.
Hi,

May I know if there is any update on this issue.

Thanks,
Shriom
Any fixes on this. ?
The bug to watch is bug 558184, which should get done (and possibly backported) this cycle.
Been a few months, anyone found a workaround?
Maybe someone useful this solution 

"you have to disable the bugged and native PDF viewer (pdf.js) in about:config. Set the pdfjs.disabled property to true and you will see the print window appearing using your script."

http://stackoverflow.com/questions/15011799/firefox-19-print-pdf-from-javascript#answer-21500997

and more


http://stackoverflow.com/questions/15011799/firefox-19-print-pdf-from-javascript#answer-25490208
Disabling PDF.js doesn't work
How come there is no proper solution for this after all these people reporting it.
I receive a 'Error: Permission denied to access property "print"' too, when trying to print a PDF.js frame (or window).

Is there any reason why this should not be possible? What's the "permission" gap mentioned in the error message? As same-origin is affective, I can't see how "allow javascript print" would annoy/exploit people.
> What's the "permission" gap mentioned in the error message?

In brief, the actual browser-provided scripts in the pdf.js frame are not running with the origin of the website the PDF came from.  They're running with an origin that has more privileges that are needed for pdf.js to work.  So when website code tries to touch the object in that frame it gets a security exception.

This also answers comment 29: there is no proper solution yet because fixing this requires significantly rearchitecting how pdf.js works unless the security model is changed.

Bobby, given the jsplugins back-burnering situation, I'd really like us to think seriously about allowing cross-origin calls to print() in this specific case.
Flags: needinfo?(bobbyholley)
Spoke with jst about this today. Peter is really on the cusp of landing his stuff (which was ready to land last month but got broken by APZ), so we should be super close here.
Flags: needinfo?(bobbyholley)
I was able to get past this bug by updating my compatibility.js to latest version..
(In reply to aokegbile from comment #33)
> I was able to get past this bug by updating my compatibility.js to latest
> version..

Can you advise me on how to update compatibility.js to latest version? Im using Mozila Firefox 47.0 on Windows.
the truth I achieved so much after reading blogs , I could make printing files with the following code I hope will be helpful ...

file html:
<head>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js" />
<script >
	$(document).ready(function() {
		$(".pdf-print").live("click",function () {
			$('#visualizador-pdf').get(0).contentWindow.focus(); 
	        window.print();
		});
	});
</script>
</head>
<body>
<div id="visualizador-pdf-div">
<iframe  id="visualizador-pdf" name="visualizador-pdf" src="pdf/Comparendo_Aprobado_1491.pdf" height="400" width="521"></iframe>
 <a class="pdf-print" id="wp-submit">Imprimir</a>
</div>

</body>
@style-orate, this way you print the whole page not the iframe. So, it does not fix anything.
Three years since the first report, 9 months after being 'super close' ... will we see a solution to this before ze germans get here?
+1
We should have figured out a fix for this now... 

Please fix this asap, it is a very vital function and the only option for cross browser compatibility of creating a print button.
I dont know why mozilla is starching this issue long. We have same functions in chrome and IE but for firefox iframe is not working. neither we can set  option from programing to set the pdf viewer so that same printout is coming from all the browsers.

Please fix this this is height of any issue. Please let us know if this is issue will not resolved in the future so that we can advice the customer that our web is not compatible in firefox anymore so that its big relief  for us.
The fix is being worked on; it's to switch to a different PDF viewer with a different security setup that does not have this issue.
Any update on this? Our customer issues are rising to peak!!
You can use the solution in #c35 (https://bugzilla.mozilla.org/show_bug.cgi?id=911444#c35) for now, it's working for me. ;)
#c35 will print whole page not specific iframe
Oops, you're write, my bad.
are we expect any date or its permanent bug in firefox which can not be resolved ?
There isn't a clear date yet; there are a lot of issues left to fix with the new PDF viewer.

But it's being actively worked on.  Chances are it's several more months before it's ready.
Is there any update on this issue? or any alternate solution to this?
Peter, do you know what the status there is?
Flags: needinfo?(peterv)
Kind of insane that 5 years later this is still a bug, please provide a status or at least say you are not going to fix it?
(In reply to cody from comment #50)
> Kind of insane that 5 years later this is still a bug, please provide a
> status or at least say you are not going to fix it?

Yes, its very bad limitation of firefox for any simple developer. We have many plugins which says that our functionality of print will works fine in all the browser except firefox so please use chrome for better result.

ex: See the comment in "http://printjs.crabbly.com/". This plugin very useful for print anything and any part of the website but its not working in firefox.

Firefox currently doesn't allow printing PDF documents using iframes. There is an open bug in Mozilla's website about this. When using Firefox, Print.js will open the PDF file into a new tab.

Very bad support . After 5 year we are not able to get the fix..... very bad
Seems like a duplicates of #874200
I am also using printJS and it would be really great if this issue were fixed ;)
Any progress from anyone on this ?
Any progress with this Bug?
5 years is not enough to resolve problem?
or may be it is not bug , some special feature?
I finally created an issue at the root cause project. This bug is due to pdf.js

https://github.com/mozilla/pdf.js/issues/10290
After a lengthy chat in the pdf.js github issue it has become clear that:

**There is no way to create a work-around Firefox security policy in pdf.js, when print() is called. Hence print() will always throw in Firefox because of how pdf.js is embedded in Firefox.**

I've asked for guidance on how to solve this issue in Firefox. https://github.com/mozilla/pdf.js/issues/10290#issuecomment-441238004
Actually pdf.js is already doing the right thing. We just need firefox to dispatch print() on the document that embeds pdf.js.
I should note that even if the security policy changes to allow calling window.print() here, that will likely not print the PDF usefully without various other work...
I think the first step forward here is to decide if we are keeping the js plugins code. If we are, we could potentially migrate pdf.js to it. However, I was pinged a few months ago about someone wanting to remove the js plugins code, so I'm really not sure about the status of it. I'd think peterv would know the most, but he's already need info'd on this bug.

Boris, any thoughts on who else would know about js plugins?
Flags: needinfo?(bzbarsky)
Peterv.

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.

Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Flags: needinfo?(peterv)
Flags: needinfo?(bzbarsky)

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

Attachment #9128224 - Attachment is obsolete: true
Attachment #9128223 - Attachment description: Bug 911444 part 5. Expose a print method on PDF viewer windows. → Bug 911444 part 4. Expose a print method on PDF viewer windows.
Pushed by bzbarsky@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fd2e3e8728d9
part 1.  Factor out the "is pdf viewer" code so we can reuse it. r=bholley
https://hg.mozilla.org/integration/autoland/rev/b96d0a37ed1a
part 2.  Allow sending an nsIPrincipal in a variant over IPC. r=nika
https://hg.mozilla.org/integration/autoland/rev/a32592af0b11
part 3.  Store the principal a PDF viewer document would have had if the PDF viewer had not messed with the principal. r=bdahl,bholley
https://hg.mozilla.org/integration/autoland/rev/d156bbaabbd5
part 4.  Expose a print method on PDF viewer windows. r=bholley

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.

Flags: needinfo?(bzbarsky)

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>

?

Flags: needinfo?(nx-2000)
Pushed by bzbarsky@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c27d113d6f61
part 1.  Factor out the "is pdf viewer" code so we can reuse it. r=bholley
https://hg.mozilla.org/integration/autoland/rev/de114a360687
part 2.  Allow sending an nsIPrincipal in a variant over IPC. r=nika
https://hg.mozilla.org/integration/autoland/rev/c0e52b90c522
part 3.  Store the principal a PDF viewer document would have had if the PDF viewer had not messed with the principal. r=bdahl,bholley
https://hg.mozilla.org/integration/autoland/rev/e681c2a6d146
part 4.  Expose a print method on PDF viewer windows. r=bholley

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.

Flags: needinfo?(nx-2000)

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)

Blocks: 1618626

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

(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

You need to log in before you can comment on or make changes to this bug.