#50474: refactor: remove dead named-window lookup from guest-window-manager
The frameNamesToWindow map was a holdover from the BrowserWindowProxy IPC shim. Since nativeWindowOpen became the only code path in #29405, Blink's FrameTree::FindOrCreateFrameForNavigation resolves named window targets directly in the renderer, scoped to the opener's browsing context group. When a matching named window exists, Blink navigates it without ever sending a CreateNewWindow IPC to the browser — so this JS-side map was never consulted in the legitimate same-opener case.
The only time the map found a match was when two unrelated renderers happened to use the same target name, in which case openGuestWindow would short-circuit before consuming the guest WebContents that Chromium had already created for the new window, leaking it.
Adds a test verifying Blink handles same-opener named-target reuse end-to-end (same WindowProxy returned, existing child navigated, setWindowOpenHandler not re-invoked) without any browser-side tracking.
Notes: none
Backports
Semver Impact
Semantic Versioning helps users understand the impact of updates:
- Major (X.y.z): Breaking changes that may require code modifications
- Minor (x.Y.z): New features that maintain backward compatibility
- Patch (x.y.Z): Bug fixes that don't change the API
- None: Changes that don't affect using facing parts of Electron