Closed Bug 1702867 Opened 3 years ago Closed 3 years ago

Firefox crashes when printing document where crossOriginIsolated == true (if served with non-default port)

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Version:
Firefox 87
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
89 Branch
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox87 --- wontfix
firefox88 --- verified
firefox89 --- verified

People

(Reporter: ed.puckett, Assigned: emilio)

References

(Regression)

Details

(Keywords: regression)

Crash Data

Attachments

(1 file)

Bug 1702867 - Static print documents do have a browsing context and are loaded as data. r=ttung,smaug
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
Details | Review

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

Load a simple web page:

<!DOCTYPE html>
<html lang="en">
<body>
</body>
</html>

loaded from a server at http://127.0.0.1:7777/c.html

with these response headers (in addition to standard ones such, e.g., as Content-Type):

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin
Cross-Origin-Opener-Policy:   same-origin

(Note: in developer tools, crossOriginIsolated == true)

Print (via CTRL-P)

Actual results:

"Tab crash reporter" page pops up: "Gah. Your tab just crashed.", displaying options to report, close/restore tab.

Expected results:

Print preview should appear.

Note that the crash no longer occurs when I simply stop serving just the "Cross-Origin-Embedder-Policy" header (and, not sure if this is relevant, but mentioning it just in case: consequently crossOriginIsolated == false).

The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Printing: Output
Product: Firefox → Core

Do you have a crash report I could look at? I'll check on Monday anyways. Thanks!

Flags: needinfo?(ed.puckett)

I found these files in ~/.mozilla/firefox/Crash Reports/pending:

-rw-rw-r-- 1 ed ed 445742 Apr 3 03:42 0130068d-e592-59af-994e-b0799484841d.dmp
-rw------- 1 ed ed 36247 Apr 3 03:42 0130068d-e592-59af-994e-b0799484841d.extra
... and others ...

Are these what you want?

Flags: needinfo?(ed.puckett)

Those are pending submission. You can submit them via about:crashes, there should be a link after they get submitted :)

Thank you!

Assignee: nobody → emilio
Status: UNCONFIRMED → ASSIGNED
Crash Signature: [@ mozilla::dom::Document::SetScopeObject ]
Ever confirmed: true
Flags: needinfo?(emilio)

Hmm, this seems to be working fine on Nightly and 87 for me... Am I missing something? My test-case is this, which prints crossOriginIsolated (and also, has the right headers according to the network tab). Do you have any extension or something that could potentially affect something like this?

Flags: needinfo?(ed.puckett)

I couldn't repro serving that from localhost either, just in case that was relevant :/

Flags: needinfo?(emilio)

I just tried your test case and my results agree with yours: no crash. I will try to find out how my test case differs from yours and get back to you. Thank you.

I just tried my minimal page again, and it still crashes for me here. I am serving from http://127.0.0.1:7777 (note: not https).

Here are the response headers:

HTTP/1.1 304 Not Modified
X-DNS-Prefetch-Control: off
Expect-CT: max-age=0
X-Frame-Options: SAMEORIGIN
X-Download-Options: noopen
X-Content-Type-Options: nosniff
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: no-referrer
X-XSS-Protection: 0
Access-Control-Allow-Origin: http://127.0.0.1:7777
Vary: Origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin
Cross-Origin-Opener-Policy: same-origin
Accept-Ranges: bytes
Cache-Control: public, max-age=0
Last-Modified: Tue, 06 Apr 2021 16:49:56 GMT
ETag: W/"38-178a81733f9"
Date: Tue, 06 Apr 2021 16:51:35 GMT
Connection: keep-alive
Keep-Alive: timeout=5

Flags: needinfo?(ed.puckett)

One other thing: I am on Ubuntu Linux 20.04. Firefox 87.0.

I added a bunch of those headers to my test-case, and still no signs of the crash, so there's probably something more subtle...

Could it be http vs https?

No, because my test-case can also be served with http: http://crisal.io/tmp/coep.php

However! I can reproduce if I use some non-default port in my localhost. E.g. if I change the default port to be 8888, then I do get the crash... These three headers are enough:

Header add Cross-Origin-Embedder-Policy "require-corp"
Header add Cross-Origin-Resource-Policy "same-origin"
Header add Cross-Origin-Opener-Policy "same-origin"

So there's something about the port, that's something to dig into!

Flags: needinfo?(emilio)
Summary: Firefox crashes when printing document where crossOriginIsolated == true → Firefox crashes when printing document where crossOriginIsolated == true (if served with non-default port?)

Great! Good luck! Thank you!

Ok, so I bisected this, and this was regressed by bug 1685475:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5d7c420165e906830e8712b84113a6c0c4c095cc&tochange=fef805bdd35c1124a4c8c15bb91b8eabda964b2f

I think I can see why (print docs are loaded as data, because they have no requests, but they do have a browsing context, as a matter of fact).

But what I don't understand is how or why the port matters. Tom, do you know?

Flags: needinfo?(emilio) → needinfo?(shes050117)
Regressed by: 1685475
Summary: Firefox crashes when printing document where crossOriginIsolated == true (if served with non-default port?) → Firefox crashes when printing document where crossOriginIsolated == true (if served with non-default port)
Has Regression Range: --- → yes

Document::CrossOriginIsolated() was assuming this wasn't possible,
so when you print from an isolated page from a different site, then we
end up with the wrong docgroup.

Ok, I know why the port is relevant now of course. when you're isolated, we isolate by the whole origin, so if the port (or subdomain) isn't different, then there's no issue. The test-case reproduces on https://www.crisal.io/tmp/coep.php (note the www).

Patch above fixes it and I think is the right fix, and also includes a test.

Flags: needinfo?(shes050117)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/824c61d6f3df
Static print documents do have a browsing context and are loaded as data. r=smaug

https://hg.mozilla.org/mozilla-central/rev/824c61d6f3df

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox89: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch

Comment on attachment 9213899 [details]
Bug 1702867 - Static print documents do have a browsing context and are loaded as data. r=ttung,smaug

Beta/Release Uplift Approval Request

  • User impact if declined: comment 0
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: go to https://www.crisal.io/tmp/coep.php, avoid the security warning, and print.
  • List of other uplifts needed: none
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Straight-forward fix to a bad assumption made in the regressing bug.
  • String changes made/needed: none
Attachment #9213899 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9213899 [details]
Bug 1702867 - Static print documents do have a browsing context and are loaded as data. r=ttung,smaug

Approved for 88.0b9. Thanks as always for improving our test coverage too :)

Attachment #9213899 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Reproduced this issue on Windows 10 x64. Crash ID: bp-74d367f1-e314-479c-be48-acd230210408.

Confirming the fix on Ubuntu 20.04 and Windows 10 x64 with:

  • 89.0a1 Nightly, buildID 20210407094544
  • 88.0b9 (treeherder), build ID 20210407185743.
Status: RESOLVED → VERIFIED
status-firefox88: fixed → verified
status-firefox89: fixed → verified
Flags: qe-verify+

Thank you Emilio and all the other excellent people!

I just now confirmed that my application no longer crashes as a result of printing after sending the 'Cross-Origin-Embedder-Policy': 'require-corp' header. The new non-crashing behavior is under Firefox 88, which came to me as part of normal updates.

Thank you to the excellent Firefox team!

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

Attachment

General

Creator:
Created:
Updated:
Size: