MarshallOfSound

#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 / keyboardLock permission requests are made for the frame that called the API rather than always the primary main frame, so setPermissionRequestHandler sees that frame's requestingUrl / 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 the clipboard-read check 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

42-x-y
In-flight
PR Number
#53702
Waiting to be merged
43-x-y
In-flight
PR Number
#53701
Waiting to be merged
44-x-y
Merged
PR Number
#53693
Merged At
Sep 7, 2026, 2:44:52 PM
Released In
Not yet
Release Date
Not yet
45-x-y
Merged
PR Number
#53692
Merged At
Sep 7, 2026, 2:24:19 PM
Released In
Not yet
Release Date
Not yet

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