STR:

1. From a content script, call window.open().document.write("xxx")

Expected:

• A popup should open, with the content xxx.

Actual:

• A popup opens and stays blank.

• The global JS console shows:

  SecurityError: Permission denied to access property "document" on cross-origin object

Just like bug 1613779, a poor (but functional) work-around is to unwrap the DOM object (window in this case, document in the other). It seems that the use of an expanded principal here causes the new window to use the null principal, instead of the document's principal.

( this issue was originally reported at https://bugzilla.mozilla.org/show_bug.cgi?id=1317166#c10 )

I put a breakpoint in GDB on nsContentUtils::IsExpandedPrincipal and continued until ep was a pointer to an nsIExpandedPrincipal, and found why the principal is downgraded to the null principal:

nsWindowWatcher::OpenWindowInternal calls nsGlobalWindowOuter::SetInitialPrincipalToSubject(csp). From the call site, it is not obvious that the calling context is relevant. However, SetInitialPrincipalToSubject uses nsContentUtils::SubjectPrincipalOrSystemIfNativeCaller(), which returns the extension's content script's expanded principal: https://searchfox.org/mozilla-central/rev/fca0be7e2cf2f922c9b927423ce28e8a04b3fd90/dom/base/nsGlobalWindowOuter.cpp#1533,1539,1542

From the functional point of view, this should ideally be the document's content principal.
This logic was introduced in bug 996069 and updated in bug 1300831. In both cases, the goal is to avoid using an expanded principal for (new) documents. These requirements are still satisfied if we convert a nsEP[contentPrincipal, extensionPrincipal] to a contentPrincipal.

I'm considering to replace the unconditional principal = nullptr assignment to something like principal = contentPrincipalIfExtensionExpandedPrincipalOrNull(principal) (with a less insane name).

assigned bug over a year ago, moving to re-triage