Make programmatic printing of iframes containing PDFs sane
Categories
(Firefox :: PDF Viewer, defect, P1)
Tracking
()
People
(Reporter: bzbarsky, Unassigned)
References
Details
Right now there are various issues. See bug 911444 and its many dups for how much people want this. Other bugs blocking this one are also blockers for the actual thing people want to do.
|
||
Comment 1•5 years ago
|
||
The priority flag is not set for this bug.
:bdahl, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Updated•5 years ago
|
|
||
Comment 2•4 years ago
|
||
Closing as FIXED, since all blocking bugs have now been fixed.
|
||
Comment 3•4 years ago
|
||
(In reply to Jonas Jenwald [:Snuffleupagus] from comment #2)
Closing as FIXED, since all blocking bugs have now been fixed.
Hi @Snuffleupagus. I see that your patch https://github.com/mozilla/pdf.js/pull/12970 to pdf.js has been merged and all bugs related to this bug (1618626) seems to have been fixed. Do you have any idea when we can test this out? I got Firefox 86.0b7 on the aurora channel.
I'm very excited to try our your work!
|
|
||
Comment 4•4 years ago
|
||
Do you have any idea when we can test this out?
As indicated by the "Milestone"-field in this bug, it's available in Firefox 87 (which is the current Nightly version).
Hence you can either use the latest Nightly version right now, or simply wait for Firefox 87 to move into the Aurora channel (which will happen in approximately two weeks time according to this).
|
|
||
Comment 5•4 years ago
|
||
(In reply to Jonas Jenwald [:Snuffleupagus] from comment #4)
Do you have any idea when we can test this out?
As indicated by the "Milestone"-field in this bug, it's available in Firefox 87 (which is the current Nightly version).
Testing with Firefox 87.0a1 (2021-02-09) this bug is unresolved. It's difficult for me to find which ticket refers to updating pdf.js with your latest patch - is it even released yet?
I tested the following simple setup:
<html>
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
<body>
<iframe src="test.pdf"></iframe>
<script>
frames[0].onload = function () {
try {
frames[0].print();
} catch (e) {
console.error("Exception thrown: " + e);
}
}
</script>
</body>
</html>
Where both the HTML file and PDF file is served via python3 -m http.server.
I get the following error: Warning: TT: undefined function: 32 pdf.worker.js:1073:13
I just found view-source:resource://pdf.js/build/pdf.worker.js and it's version 2.8.61 (which is even newer than the latest release on github.com).
I found your patch changes in resource://pdf.js/web/viewer.js.
Does frames[0].print(); work for you @:Snuffleupagus?
|
|
||
Comment 6•4 years ago
|
||
Seems that window.frames[0] is wrong since it returns the contentWindow (https://developer.mozilla.org/en-US/docs/Web/API/Window/frames).
More discussion here:
https://groups.google.com/g/mozilla.dev.platform/c/VijG80aFnU8
The following works as expected:
<html>
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
<body>
<iframe id="printPdf" src="test.pdf"></iframe>
<script>
window.printPdf.onload = function () {
console.log('Onload fired!')
try {
frames[0].print();
} catch (e) {
console.error("Exception thrown: " + e);
}
}
</script>
</body>
</html>
The console.log output is:
GET http://localhost:8000/favicon.ico [HTTP/1.0 404 File not found 0ms]
Partitioned cookie or storage access was provided to “<URL>” because it is loaded in the third-party context and storage partitioning is enabled. 4
PDF 5acdaccbd792e54480a36df80ed80827 [1.7 Adobe Acrobat Pro 10.0.0 / Adobe Acrobat Pro 10.0.0] (PDF.js: 2.8.61) viewer.js:1948:13
Warning: TT: undefined function: 32 pdf.worker.js:1073:13
Warning: TT: undefined function: 32 pdf.worker.js:1073:13
Onload fired!
Thank you Jonas!
My only concern is if it's expected that contentWindow does not have a load event but that seems out of scope for this ticket.
|
|
||
Comment 7•4 years ago
|
||
Actually, after thinking it over. The title for this ticket is "Make programmatic printing of iframes containing PDFs sane".
I think it is reasonable to expect the onload event to fire on frames[0]/contentWindow.
Would you consider re-opening this ticket :Snuffleupagus?
Some WPT tests look relevant to catch the missing onload event, e.g. iframe-load-event.html and perhaps some more in the same folder https://github.com/web-platform-tests/wpt/tree/master/html/semantics/embedded-content/the-iframe-element.
Opera 73.0.3856.344 and Microsoft Edge 88.0.705.6, both fires the onload event for frames[0] and the previous posted PDF print example work as expected.
For Firefox, it works if the iframe points to an HTML file but not to a PDF file.
I will try to come up with a reasonable real-world example to test with.
|
|
||
Comment 8•4 years ago
•
|
||
This is essentially a tracking bug, since all referenced work has happened in other bugs.
Hence any further problems should be reported in new bugs, rather than here, and without having added any new (confirmed) "depends on" bugs it seems unnecessary to re-open this.
|
|
Reporter | |
Comment 9•4 years ago
|
||
My only concern is if it's expected that contentWindow does not have a load event but that seems out of scope for this ticket.
contentWindow does, but in this case the load event is set up before the load happens, and the load creates a new contentWindow because the PDF renderer is not same-origin with the parent page... So the window the load listener was set up on is thrown out when the PDF renderer is set up.
Making that work would involve having the PDF renderer actually run in the origin of the PDF....
I think it is reasonable to expect the onload event to fire on frames[0]/contentWindow.
They do. But the thing they fire on is not the thing the listener was added on. Expecting the listener to persist across a security boundary switch there (which to be clear is a process switch too) is not reasonable, unfortunately....
|
|
||
Comment 10•4 years ago
|
||
Thanks for the explanation :bzbarsky.
So far, every way I have tried to reference the PDF iframe, except frames[0].onload, has worked beautifully. E.i. document.createElement('iframe') and document.querySelector.
It seems odd that frames[0] is the only time when contentWindow is replaced after I set a load listener. But it is really not a problem.
I think it's rare that anyone would use the frame list and not a document element selector method.
Thanks, to both of you, for your work on this issue - it's greatly appreciated!
|
|
Reporter | |
Comment 11•4 years ago
|
||
contentWindow is always replaced if the thing that eventually loads doesn't have the same origin as the initial about:blank. document.querySelector returns the iframe element itself, and a listener added to that will fire any time a new document is loaded in the iframe. frames[0] returns the Window inside the iframe; a listener added to that will only fire when the load of that specific document completes.
You could do frames[0].frameElement and it would work as well as the document.querySelector approach, if that code runs before the load has progressed far enough that the document in the iframe is the PDF document, not about:blank.
Description
•