Closed Bug 1618626 Opened 1 year ago Closed 5 months ago

Make programmatic printing of iframes containing PDFs sane

Categories

(Firefox :: PDF Viewer, defect, P1)

defect

Tracking

()

RESOLVED FIXED
87 Branch

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.

Depends on: 1618955

The priority flag is not set for this bug.
:bdahl, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(bdahl)
Flags: needinfo?(bdahl)
Priority: -- → P1

Closing as FIXED, since all blocking bugs have now been fixed.

Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch

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

Flags: needinfo?(jonas.jenwald)

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

Flags: needinfo?(jonas.jenwald)

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

Flags: needinfo?(jonas.jenwald)

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.

Flags: needinfo?(jonas.jenwald)

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.

Flags: needinfo?(jonas.jenwald)

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.

Flags: needinfo?(jonas.jenwald)

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

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!

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.

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