The shown diff is a WebKit feature-preference change, not the keyboard-lock logic itself, so the mechanism below is partly inferred from the flag’s purpose and the advisory (‘framing malicious content may lead to UI spoofing’). In UnifiedWebPreferences.yaml the FullScreenKeyboardLock preference — the Fullscreen API-based Keyboard Lock feature (Keyboard.lock()) — was marked status: stable and defaulted to true for WebKitLegacy, WebKit and WebCore. Keyboard Lock lets a page in fullscreen intercept normally reserved keys (including Escape and system chords) so they are delivered to the page rather than the browser/OS. The problem, per the advisory, is that when a site FRAMES malicious content and that content enters fullscreen with keyboard lock, it can capture the keys a user would use to leave fullscreen or regain trusted UI, so the framed content can present a spoofed, inescapable full-screen interface (UI spoofing) — the violated invariant is that the user must always be able to exit fullscreen and reach trusted browser UI, which keyboard lock in a framed/hostile context defeats.

The fix flips the feature to status: unstable and defaultValue false across WebKitLegacy/WebKit/WebCore, disabling Fullscreen Keyboard Lock by default so pages can no longer trap those keys until the feature is reworked. The restored behavior is that Escape/system keys are not silently captured by (framed) fullscreen content by default. This is a policy/hardening change (turn a risky capability off by default); the keyboard-lock enforcement code that would gate framed use is not in this diff.

A UI-spoofing / user-deception issue in the WebContent process with no memory corruption: framed content could use fullscreen keyboard lock to trap the user and present a spoofed interface. Impact is phishing/social-engineering rather than code execution; the mitigation simply disables the risky capability by default.