Closed Bug 754156 Opened 8 years ago Closed 7 years ago

"Assertion failure: principals == JS_GetCompartmentPrincipals((js::GetContextCompartment(cx)))" with view-source, pushState

Categories

(Core :: XPConnect, defect, critical)

x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox14 --- unaffected
firefox-esr10 --- unaffected

People

(Reporter: jruderman, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, sec-moderate, testcase)

Attachments

(3 files)

Attached file imgTag.html
1. Save imgTag.html and c.html in the same directory.
2. Set security.fileuri.strict_origin_policy to false.
3. Load c.html
4. Push the big red button.

Result:

Assertion failure: principals == JS_GetCompartmentPrincipals((js::GetContextCompartment(cx))), at caps/src/nsScriptSecurityManager.cpp:208

This is a regression from cpg (ac00c792933e is ok, 400c2b30015d asserts).
Attached file c.html (testcase)
Attached file stack trace
I'm not too worried about this. It looks like the compartment principal here doesn't match the result of doGetObjectPrincipal. Probably some edge case with view-source, which tends not to be a problem in practice.

Unless the real issue here is that the compartment principal is incorrect, this will just go away when we rip out this code in bug 754202.
Depends on: 754202
Just a note that i ran into this same assertion when opening the web console to try and debug some tests i was adding to iframe sandbox - see bug 341604 comment 144 and comment 149 for more details.
(In reply to Ian Melven :imelven from comment #4)
> Just a note that i ran into this same assertion when opening the web console
> to try and debug some tests i was adding to iframe sandbox - see bug 341604
> comment 144 and comment 149 for more details.

also in this case, there's a crash with a null pointer deref after the assertion.
What about other nested URI types, like jar: ?
Keywords: sec-moderate
I'm guessing that this will be fixed by bug 764389.
Depends on: 764389
(In reply to Bobby Holley (:bholley) from comment #8)
> I'm guessing that this will be fixed by bug 764389.

I can not reproduce the assertion with the urls in comment 7 on this morning's debug Nightly/16 but still can with Aurora/15 so at least as far as cross_fuzz is concerned it does look like this was fixed.
Can somebody check this on 15?  Bobby landed 764389 since comment 9.  It would probably also be good to check Jesse's original test case.
(In reply to Bobby Holley (:bholley) from comment #8)
> I'm guessing that this will be fixed by bug 764389.

So is this bug fixed?
I'd think so. Jesse, can you confirm?
Flags: needinfo?(jruderman)
Now I get:

JavaScript error: file:///Users/jruderman/Desktop/c.html, line 10: NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIDOMHistory.pushState]

I'll take it.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(jruderman)
Resolution: --- → WORKSFORME
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.