electron

electron copied to clipboard

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

• [x] PR description included and stakeholders cc'd
• [x] npm test passes
• [x] tests are changed or added
• [x] relevant documentation is changed or added
• [x] 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.

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

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.

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!

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

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

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

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

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

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).

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.

Release Notes Persisted

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

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