#55030: fix: use the opener's session and webPreferences for windows opened from links
Merged
Created: Oct 15, 2026, 5:04:38 PM
Merged: Oct 16, 2026, 2:54:37 AM
11 comments
Target: main
Description of Change
Windows opened by middle- or modifier-clicking a link were assembled in JS from a -new-window event with new BrowserWindow(options), so unlike window.open() popups they didn't pick up the opener's session or inherited webPreferences and landed in the default session with defaults.
This creates those windows the same way window.open() popups are created: OpenURLFromTab runs -will-add-new-contents, creates the WebContents in the opener's browser context with the handler's preferences, and hands it to -add-new-contents.
- removes
-new-window, the guest-less branch ofopenGuestWindowand the internalopenerSandboxFlagspreference (flags go straight ontoCreateParams) createWindownow always receivesoptions.webContents; docs example updatedAddNewContentsreports a rejected window viawas_blockedso it isn't navigated
Checklist
- I have built and tested this change
- I have filled out the PR description
- I have reviewed and verified the changes
-
npm testpasses - tests are changed or added
- relevant API documentation, tutorials, and examples are updated and follow the documentation style guide
- PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, past tense, and no longer than 80 characters.
Release Notes
Notes: Fixed link-opened windows not using the opener's session and webPreferences.
Backports
Semver Impact
Major
Breaking changes
Minor
New features
Patch
Bug fixes
None
Docs, tests, etc.
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