#53664: fix: attribute pointer lock, keyboard lock and paste checks to the requesting frame
Merged
Created: Sep 7, 2026, 4:05:35 AM
Merged: Sep 7, 2026, 12:43:17 PM
7 comments
Target: main
pointerLock/keyboardLockpermission requests are made for the frame that called the API rather than always the primary main frame, sosetPermissionRequestHandlersees that frame'srequestingUrl/isMainFrame.document.execCommand('paste')is allowed on transient user activation of the requesting frame (as in Chrome) instead of any recent interaction in the WebContents; otherwise theclipboard-readcheck decides as before.- Docs: drop the "always appear to originate from the main frame" notes.
Notes: pointerLock and keyboardLock permission requests now report the requesting frame, and execCommand('paste') requires user activation in the frame that calls it.
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