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

NEW
Unassigned
(Needinfo from 2 people)

Status

()

defect
P3
normal
6 years ago
3 months ago

People

(Reporter: justin.felisco, Unassigned, NeedInfo)

Tracking

23 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [pdfjs-c-integration])

(Reporter)

Description

6 years ago
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.
(Reporter)

Updated

6 years ago
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
(Reporter)

Comment 3

6 years ago
(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.
(Reporter)

Comment 4

6 years ago
(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.

Comment 8

5 years ago
Any update on the resolution...I am facing this too..

Comment 9

5 years ago
Is anyone looking at this? Is there a workaround. Please note that the embedded frame is on the same domain.

Comment 10

5 years ago
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.

Comment 16

5 years ago
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.
Duplicate of this bug: 647658

Comment 19

4 years ago
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.

Comment 21

4 years ago
Hi,

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

Thanks,
Shriom

Comment 22

4 years ago
Any fixes on this. ?
The bug to watch is bug 558184, which should get done (and possibly backported) this cycle.

Comment 24

4 years ago
Been a few months, anyone found a workaround?

Comment 25

4 years ago
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

Updated

4 years ago
Duplicate of this bug: 1202197

Comment 27

4 years ago
Disabling PDF.js doesn't work

Updated

3 years ago
Duplicate of this bug: 1232097

Comment 29

3 years ago
How come there is no proper solution for this after all these people reporting it.

Comment 30

3 years ago
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)

Comment 33

3 years ago
I was able to get past this bug by updating my compatibility.js to latest version..

Comment 34

3 years ago
(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.

Comment 35

3 years ago
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.

Comment 37

3 years ago
Three years since the first report, 9 months after being 'super close' ... will we see a solution to this before ze germans get here?

Comment 38

3 years ago
+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.

Comment 40

2 years ago
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.

Comment 42

2 years ago
Any update on this? Our customer issues are rising to peak!!

Comment 43

2 years ago
You can use the solution in #c35 (https://bugzilla.mozilla.org/show_bug.cgi?id=911444#c35) for now, it's working for me. ;)

Comment 44

2 years ago
#c35 will print whole page not specific iframe

Comment 45

2 years ago
Oops, you're write, my bad.

Comment 46

2 years ago
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.

Comment 48

2 years ago
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)

Comment 50

a year ago
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?

Comment 51

9 months ago
(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

Comment 52

7 months ago
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 ?

Comment 53

5 months ago
Any progress with this Bug?
5 years is not enough to resolve problem?
or may be it is not bug , some special feature?

Comment 54

5 months ago
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

Comment 55

5 months ago
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

Comment 56

5 months ago
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)

Comment 60

3 months ago

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>";
?>

Comment 61

3 months ago

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

Comment 62

3 months ago

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.

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