- From: Philip Jägenstedt <notifications@github.com>
- Date: Fri, 08 May 2026 01:54:19 -0700
- To: whatwg/fullscreen <fullscreen@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fullscreen/pull/232/review/4250910667@github.com>
@foolip commented on this pull request.
> +like ESC or function keys are integral to the application's functionality.
+
+<p>A <a>keyboard lock</a> enables web applications to capture and handle key inputs directly,
+bypassing the default behavior typically executed by the user agent or operating system. Key events
+that would normally trigger user agent or system-level actions are instead redirected to the web
+application in fullscreen. Such key events (for individual keys or keyboard shortcuts) may either
+have no action while <a>keyboard lock</a> is active, or it could still have the same action but
+allow the web page to call {{Event/preventDefault()}} to cancel the action.
+
+<p>Whenever a <a>document</a>'s <a>keyboard lock</a> is changed from active to inactive, user agents
+must deactivate the keyboard lock and restore the handling of keyboard inputs to the default
+behavior of the user agent and the operating system.
+
+<p>User agents should reserve an additional input for the purposes of exiting fullscreen. There are
+also some system-level key sequences or combinations that cannot be intercepted for security
+reasons, such as Ctrl+Alt+Del on Windows.
@marcoscaceres I'll go ahead and merge this, but if you want changes later just file a new issue or PR.
--
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fullscreen/pull/232#discussion_r3207536817
You are receiving this because you are subscribed to this thread.
Message ID: <whatwg/fullscreen/pull/232/review/4250910667@github.com>
Received on Friday, 8 May 2026 08:54:26 UTC