Layout debugger can trigger debug assertion "Receiving unexpected Principal" after fission enabled
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: TYLin, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
I can reproduce this after fission enabled by default in bug 1732358.
Steps to reproduce:
- Build Firefox in debug mode.
- Run
./mach run -layoutdebug https://bugzilla.mozilla.org/attachment.cgi?id=9074885
(Loading any bugzilla testcase withhttps://bugzilla.mozilla.org/
will reproduce)
Actual result:
Triggers the debug assertion "Receiving unexpected Principal" in ContentParent::LogAndAssertFailedPrincipalValidationInfo()
at
https://searchfox.org/mozilla-central/rev/7f1db1d2c556b82114b62f5aa4aa29397ad5bce4/dom/ipc/ContentParent.cpp#1330-1334
Expect result:
No debug assertion.
Observation:
https://bugzilla.mozilla.org/attachment.cgi?id=9074885 redirects to https://bug1377072.bmoattachments.org/attachment.cgi?id=9074885, and running ./mach run -layoutdebug https://bug1377072.bmoattachments.org/attachment.cgi?id=9074885
does not trigger the assertion
Workaround:
Set pref dom.security.enforceIPCBasedPrincipalVetting = false
Reporter | ||
Comment 1•2 years ago
|
||
Christoph, do you have any idea?
(cc some layout engineers with fission experience.)
Updated•2 years ago
|
Comment 2•2 years ago
|
||
Set release status flags based on info from the regressing bug 1732358
Updated•2 years ago
|
Updated•2 years ago
|
Comment 3•2 years ago
|
||
(In reply to Ting-Yu Lin [:TYLin] (UTC-8) from comment #1)
Christoph, do you have any idea?
Tom, can you run the testcase and suggest a path forward? I suppose once we know the stacktrace and from what unexpected IPC call that principal is coming from we can potentially relax that call? But first, we need to know what unexpected Principal it is. Thanks!
Comment 4•2 years ago
|
||
Set release status flags based on info from the regressing bug 1732358
Comment 5•2 years ago
|
||
remoteTypeSiteOriginNoSuffix = https://mozilla.org
siteOriginNoSuffix = https://bug1377072.bmoattachments.org
Comment 6•2 years ago
|
||
Also
#1 0x00007fffeff7e42a in mozilla::dom::BrowserParent::RecvNewWindowGlobal(mozilla::ipc::ManagedEndpoint<mozilla::dom::PWindowGlobalParent>&&, mozilla::dom::WindowGlobalInit const&) (this=0x7fff7816e200, aEndpoint=..., aInit=...)
Updated•2 years ago
|
Comment 7•2 years ago
|
||
:dholbert is this something we want to work on for 101?
Updated•2 years ago
|
Comment 8•2 years ago
|
||
Users are entirely unaffected by this, so it's not something we need to care about tracking from a release perspective.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Description
•