1927074 - Cannot use iframe.contentWindow.print() if Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy are both set to strict values

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[edlu8290]

https://bugzilla.mozilla.org/show_bug.cgi?id=911444 was marked as closed, but the explanation does not seem sufficient.

Even if following Daniel Holbert [:dholbert]'s suggestion, one cannot use iframe.contentWindow.print() unless Cross-Origin-Opener-Policy is set to unsafe-none, but this seems like a meaningful defect compared to Chrome / Safari.

Is this the right behavior? Shouldn't we be able to use iframe.contentWindow.print() even when Cross-Origin-Opener-Policy is set to same-origin?

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to edlu8290 from comment #0)

https://bugzilla.mozilla.org/show_bug.cgi?id=911444 was marked as closed, but the explanation does not seem sufficient.

To be specific, it was closed nearly 5 years ago when some patches landed to add formerly-missing functionality - bug 911444 Comment 99.

My recent comment on that bug is a late-breaking response to some followup questions that were posed there, regarding some issues that folks observed after the bug was closed (the main one of which was fixed in bug 1618553).

I think you've run across an entirely-different issue from what folks were posting about there, which in my testing reproduces if I set these two headers in my .htaccess file:

Header set Cross-Origin-Embedder-Policy: require-corp
Header set Cross-Origin-Opener-Policy: same-origin

(Note that both are required -- Cross-Origin-Opener-Policy: same-origin on its own doesn't result in any trouble.) I'm guessing that you probably are testing with both of those set as well.

If both of those headers are set when serving a page with an iframe-hosting-a-same-origin-PDF, I can confirm that iframe.contentWindow.print() fails in the following ways:

• Firefox release builds: no print dialog, and no effects at all other than Uncaught NS_ERROR_FAILURE: in web console.
• Firefox nightly builds: immediate content-process crash (diagnostic assert) with crash signature [@ mozilla::dom::BrowsingContext::Attach ].

Here's a testcase: https://dholbert.org/tests/1927074-also-coep/test.html
Sample crash report from Nightly, when clicking the button in that testcase: bp-e2500092-6149-4f57-bafb-a01a50241025

Comment 2

[Daniel Holbert [:dholbert]]

This might be relevant to getting client-side printing working for Google Slides, in bug 1917688.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

Is the crash a regression from bug 1925409?

Comment 4

[Daniel Holbert [:dholbert]]

looks like it, yeah. Lemme spin off a separate bug for that crash, since that's a more recent regression that might merit a band-aid to stop crashing, independently from fixing this larger issue.

Comment 5

[Daniel Holbert [:dholbert]]

I spun off bug 1927219 for the crash.

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1927074 - Set consistent opener policy for printing. r=nika!

Comment 7

[Phabricator Automation]

Comment on attachment 9433434 [details]
Bug 1927074 - Set consistent opener policy for printing. r=nika!

Revision D226964 was moved to bug 1927219. Setting attachment 9433434 [details] to obsolete.

Comment 8

[Emilio Cobos Álvarez [:emilio]]

Patch in bug 1927219 fixes this, afaict.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

Patch in bug 1927219 fixes this, afaict.

It looks like it, in my testing, yeah. Thanks!

Comment 10

[Daniel Holbert [:dholbert]]

I confirmed this is fixed in Nightly (presumably by bug 1927219). I tested using my testcase https://dholbert.org/tests/1927074-also-coep/test.html in latest Nightly, which uses the headers described in comment 1. I get a functional print-preview window for the PDF there now, when clicking the Click to trigger print... button in the outer document; whereas previously, Firefox release versions would silently fail (as noted in comment 1).

@edlu: would you mind testing a Firefox Nightly build to see if this is fixed for you too? (Firefox Nightly won't mess with your regular Firefox installation; it's a separate application, and doesn't touch your e.g. user profile data for your regular Firefox installation)

Alternately, if you'd prefer: you could provide a URL of an example page that demonstrates the problem that you were hitting, then I or someone here could verify that it's fixed with your use-case, too. Thanks!

Comment 11

[Daniel Holbert [:dholbert]]

Calling this "verified" for 133 and 134, based on bug 1927219 comment 11 which is testing the same steps here, where QA observed a print dialog being successfully generated (which is what this bug here was about us failing-to-do).

(It'd still be great to get confirmation from the reporter that this addresses their use-case, though, since so far we're working with my recreation of what-I-think-they-were-describing.)