- From: Philip Jägenstedt <notifications@github.com>
- Date: Thu, 07 May 2026 04:24:48 -0700
- To: whatwg/fullscreen <fullscreen@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fullscreen/pull/232/review/4243516531@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.
I've added that with some light edits like browser → user agent.
@marcoscaceres are you happy with this addition?
--
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fullscreen/pull/232#discussion_r3201039023
You are receiving this because you are subscribed to this thread.
Message ID: <whatwg/fullscreen/pull/232/review/4243516531@github.com>
Received on Thursday, 7 May 2026 11:24:55 UTC