Load event doesn't fire on window.open()'d pdf window (was: Unlike Chrome/Edge, the print dialog cannot be automatically triggered when a PDF file is opened in a new tab)
Categories
(Firefox :: PDF Viewer, defect)
Tracking
()
People
(Reporter: yuliiashurek, Unassigned, NeedInfo)
References
Details
Steps to reproduce:
- Create a simple index.html file with the following content:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>PDF Print Button</title>
</head>
<body>
<button onclick="openAndPrintPDF()">Open and Print PDF</button>
<script>
function openAndPrintPDF() {
var pdfWindow = window.open('sample.pdf', '_blank');
pdfWindow.onload = function() {
pdfWindow.print();
};
}
</script>
</body>
</html> - Place a PDF file named sample.pdf near index.html
- Open index.html in a browser.
- Click the "Open and Print PDF" button.
Actual results:
The PDF file should open in a new tab, and the print dialog should automatically appear (like in Chrome/Edge).
Expected results:
The print dialog does not appear automatically when the PDF is opened in the new tab.
|
||
Comment 1•29 days ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•28 days ago
|
||
Thanks for the report! So, the issue seems to be that the load event doesn't fire, right?
Test-case: https://crisal.io/tmp/print-pdf-window-open.html
If I use a timeout (see the checkbox I added to your test-case) then it works. So this is more on the DOM side of things.
|
|
||
Comment 3•28 days ago
|
||
More minimal test-case: https://crisal.io/tmp/load-pdf-window-open.html
Olli, do you know if / where do we decide to fire the load event for the window proxy? This works for iframes so it is a bit surprising that it doesn't for window.open()... FWIW I checked back to FF56 and it doesn't work there either. Maybe we're considering the PDF window cross-origin due to the pdf.js principal?
|
||
Comment 4•28 days ago
•
|
||
Yeah, pdfWindow in the example can't be accessed. So onload is added to the window when it has the initial about:blank, and load event is fired on the new inner window.
How can this work on other browsers, what is event.target when it fires?
Looks like Chrome exposes the "pdf" document to the caller, and that document has <embed> which has then the pdf.
Hmm, and various Chrome internal stuff is exposed to the web there. internalid="<some magic number>" and such.
webkit (Gnome Web at least), seems to use an iframe there, not embed.
|
|
||
Comment 5•28 days ago
|
||
I think the question here is that could we change the setup we have for pdf viewer.
|
|
||
Comment 6•28 days ago
|
||
I think the <iframe> / <embed> set-up could mostly work, though we'd want to forward print requests etc from the embedder document into the <iframe>, if we did that...
Still, seems workable. We may even be able to remove some of the special code from bug 911444...
|
|
||
Comment 7•28 days ago
|
||
I guess if we do that we should standardize on what we document looks like... Does the spec say anything about e.g. image documents?
|
|
||
Comment 8•28 days ago
|
||
window.print would be a bit magical, but I guess less magical than what was done in bug 911444.
I wonder in which cases we'd create the synthetic document for pdf, the document which had then iframe or embed.
Or, I guess that is simple, if the iframe/embed is already inside a synthetic document, then we wouldn't use such for the contents of iframe/embed itself, but the real pdf viewer would be created there.
Need to also test how this works in case of a cross-origin pdf. My guess is that the synthetic document could be always same origin. And that again would just make window.print work.
Are there other aspects to consider? Do we have different behavior in pdf viewer when the pdf is shown as the top level document vs shown inside an iframe?
|
|
||
Updated•28 days ago
|
Description
•