feat: add WebContents.opener and webContents.fromFrame()

[samuelmaddock]

Description of Change

closes #24807

Adds the ability to get the window opener of a WebContents.

// From WebContents instance
contents.opener;

// From WebFrameMain instance
webContents.fromFrame(frame)?.opener;

I'd like to also add WebFrameMain.opener, but there's no public API for this in render_frame_host.h

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation is changed or added
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes:

• Added WebContents.opener to access window opener.
• Added webContents.fromFrame(frame) to get the WebContents corresponding to a WebFrameMain instance.

[MarshallOfSound]

So if an iframe opens a child window. childWindow.webContents.opener will point to windowOwningIframe not the iframe itself?

[samuelmaddock]

So if an iframe opens a child window. childWindow.webContents.opener will point to windowOwningIframe not the iframe itself?

opener returns an instance of RenderFrameHost which would be an iframe in that case. I based the docs definition off of MDN's description. Realizing now that "window" is ambiguous though.

[nornagon]

I feel like there must be a way to validate that a RFH is controlled by a particular security origin! Perhaps SiteInstance is the way here? render_frame_host()->GetSiteInstance()->GetSecurityOrigin() maybe? Though SiteInstance isn't reliable in the face of non-site-per-process process models.

I feel like going through WebContents here is weird and wrong though. If Site A has a cross-origin iframe B in it, and B opens a child window C, would C.webContents.opener give A.webContents? That seems bad!

[nornagon]

Is this no longer needed now that we have webFrameMain.origin?

[samuelmaddock]

Is this no longer needed now that we have webFrameMain.origin?

Yeah, let's close unless we find another use case for it.

[samuelmaddock]

Is this no longer needed now that we have webFrameMain.origin?

Yeah, let's close unless we find another use case for it.

[pushkin-]

Isn't my issue that would have been fixed by this a use case? The origin from what I can tell by that PR is just the URL (unless I misinterpreted something).

[samuelmaddock]

Isn't my issue that would have been fixed by this a use case? The origin from what I can tell by that PR is just the URL (unless I misinterpreted something).

Ah yes, sorry about that. I believe the API surface is small enough that there's little risk in introducing it.

@nornagon lmk you're thoughts on still merging this to address the linked issue.

[nornagon]

hm... in what situation is there no WebContents for a WebFrameMain?

[samuelmaddock]

More accurately, this is for when the WebContents has been destroyed while the frame reference is held around. One of the tests in this PR checks this.

[nornagon]

Yeah this seems reasonable in that case. API LGTM

[jkleinsc]

API LGTM

[release-clerk]

Release Notes Persisted

• Added WebContents.opener to access window opener.
• Added webContents.fromFrame(frame) to get the WebContents corresponding to a WebFrameMain instance.

[trop]

I have automatically backported this PR to "21-x-y", please check out #35819