1966088 - window.open() from extension page results in DeadObject (TypeError: can't access dead object)

Status: NEW

(WebExtensions :: General, defect)

Description

[Rob Wu [:robwu]]

Attachment: window.open-deadobject.zip

When an extension page opens a window/popup/tab with window.open(), the return value becomes a "Dead Object" instead of a window proxy. Consequently, it is not possible to do things like window.postMessage.

STR:

1. Load attached extension.
2. Click on the window.open() button, which calls window.open().
3. Click on the "Is DeadObject?" button, which tries to access any property on the window.open() return value (supposedly a WindowProxy)

Expected:

• No errors, or: DOMException: Permission denied to access property Symbol.toPrimitive on cross-origin object

Actual:

• Error: TypeError: can't access dead object

For comparison, try this in the devtools on the web, e.g. at https://example.com:

• onclick = () => { w = window.open("https://example.net/") }
• Click anywhere in the page to open the popup (using click to bypass popup blocker)
• Evaluate w. It is a "Restricted" object, and trying to serialize it yields DOMException: Permission denied to access property Symbol.toPrimitive on cross-origin object

Might be related to bug 1947632, which shows a difference between web pages and extension pages from the perspective of the opened page (window.opener is null when opened from extension page).

Comment 1

[Rob Wu [:robwu]]

I think that this (and bug 1947632) are happening because we effectively forcing the new tab to have a different BCG (MDN: Browsing Context Group) (source code in ProcessIsolation.cpp). Consequently, the content in the opener window and new window cannot reference each other.

Something similar happens the other way around (source), when a web page loads a moz-extension:-document. Interestingly, the window reference is valid, opener in the moz-extension:-document is null, and win.postMessage in the opener does not trigger window.onmessage in the extension document.

My thought is confirmed when I run Firefox with MOZ_LOG=ProcessIsolation:5 and the STR, which generates the following log:

(initial page load of the extension document)

[Parent 77936: Main Thread]: V/ProcessIsolation DocumentLoadListener MaybeTriggerProcessSwitch [this=142f75d80, uri=moz-extension://2bc746e2-2734-426a-87f4-5b885c1ada58/tab.htm, browserid=e]
[Parent 77936: Main Thread]: V/ProcessIsolation IsolationOptionsForNavigation principal:moz-extension://2bc746e2-2734-426a-87f4-5b885c1ada58, uri:moz-extension://2bc746e2-2734-426a-87f4-5b885c1ada58/tab.htm, parentUri:
[Parent 77936: Main Thread]: V/ProcessIsolation Channel Creation Isolation Behavior: WebContent
[Parent 77936: Main Thread]: V/ProcessIsolation Found extension frame with addon policy. Will use group id 1e (currentId: 26)
[Parent 77936: Main Thread]: D/ProcessIsolation Using IsolationBehavior Extension for moz-extension://2bc746e2-2734-426a-87f4-5b885c1ada58 (original uri moz-extension://2bc746e2-2734-426a-87f4-5b885c1ada58/tab.htm)
[Parent 77936: Main Thread]: D/ProcessIsolation Selecting specific remote type (extension) due to a special case isolation behavior Extension
[Parent 77936: Main Thread]: V/ProcessIsolation CheckIsolationForNavigation -> current:(extension) remoteType:(extension) replace:1 group:1e bfcache:0 shentry:0 newTab:0
[Parent 77936: Main Thread]: I/ProcessIsolation Process Switch: Changing Remoteness from 'extension' to 'extension'
[Parent 77936: Main Thread]: V/ProcessIsolation Process Switch: Calling ChangeRemoteness

(when the button is clicked that opens example.com)

XXX Before_open
XXX After_open
XXX After_focus
[Parent 77936: Main Thread]: V/ProcessIsolation DocumentLoadListener MaybeTriggerProcessSwitch [this=142b19d80, uri=https://example.com/, browserid=100000001]
[Parent 77936: Main Thread]: V/ProcessIsolation IsolationOptionsForNavigation principal:https://example.com, uri:https://example.com/, parentUri:
[Parent 77936: Main Thread]: V/ProcessIsolation Channel Creation Isolation Behavior: WebContent
[Parent 77936: Main Thread]: V/ProcessIsolation Forcing BC replacement to leave extension BrowsingContextGroup 1e on navigation
[Parent 77936: Main Thread]: D/ProcessIsolation Using IsolationBehavior WebContent for https://example.com (original uri https://example.com/)
[Parent 77936: Main Thread]: V/ProcessIsolation Isolating 'https://example.com' as isolation is enabled for all sites
[Parent 77936: Main Thread]: V/ProcessIsolation CheckIsolationForNavigation -> current:(extension) remoteType:(webIsolated=https://example.com) replace:1 group:0 bfcache:0 shentry:0 newTab:0
[Parent 77936: Main Thread]: I/ProcessIsolation Process Switch: Changing Remoteness from 'extension' to 'webIsolated=https://example.com'
[Parent 77936: Main Thread]: V/ProcessIsolation Process Switch: Calling ChangeRemoteness

Comment 2

[Rob Wu [:robwu]]

On the web, different windows can reference each other by default, unless they opt in to restrictions, such as noopener on the opener side, or Cross-Origin Opener Policy (COOP) on the opened side.

This bug shows that for extensions, we're forcing extension BCG to be isolated from the web (as if a stricter COOP was applied on the destination, such as Cross-Origin-Opener-Policy: same-origin). Part of comment 2 ("Something similar happens the other way around (source)") shows that from the website's POV, it seems that the extension has Cross-Origin-Opener-Policy: same-origin. However, extensions cannot benefit from that restriction in the form of access to additional APIs (bug 1750654).

IF we are willing to allow extensions to relax the restrictions, we could consider adding support for cross_origin_opener_policy (default to same-origin for extensions instead of unsafe-none from the web), and allow extensions to opt out of the BCG restrictions when they specify unsafe-none.

Comment 3

[Rob Wu [:robwu]]

Tom, what are your thoughts here? Is it feasible to put the new content in the same BCG, possibly with an opt in?