When Bobby and I were talking about bug 1297687, he told me that DOM windows and such can never have an expanded principal, but nsGlobalWindow::SetInitialPrincipalToSubject() disagrees. That function allows expanded principals to be used with chrome docshells, which can cause principals observed in DOM code to be expanded principals, which ruins our setup around relying on accurate OriginAttribute information for principals of DOM windows which aren't the system principal. We should probably make that function not use an expanded principal in that case.

Boris, would you be OK with the proposed change here?

I think so, yes. In practice, this is basically used for the initial about:blank of a window.open-ed window; people doing that with an expanded principal... I'm not sure what behavior they really want.

Comment on attachment 8788603 [details] [diff] [review] Avoid creating about:blank windows with expanded principals Review of attachment 8788603 [details] [diff] [review]: ----------------------------------------------------------------- Nice find. Please sprinkle some assertions around the various document and window creation code to make sure this never happens (another bug is fine).

Comment on attachment 8788603 [details] [diff] [review] Avoid creating about:blank windows with expanded principals >+ // docshel. The last 'l' ran away. Please catch it and put it back. The upshot of this patch will be to produce a window whose about:blank is _not_ subsumed by the code that called window.open(). Maybe that's OK... Seems a little weird to me, though. [Note: in the system-principal case that's not an issue, since the system principal _does_ subsume the about:blank principal we would generate here.]

Pushed by eakhgari@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/4c763f86c462 Avoid creating about:blank windows with expanded principals; r=bholley

(In reply to Bobby Holley (PTO through 9/19/2016) (busy with Stylo) from comment #4) > Nice find. Please sprinkle some assertions around the various document and > window creation code to make sure this never happens (another bug is fine). This can certainly happen in at least three different cases, this bug being all but one. See the rest of the dependencies of the blocker bug.