To unfullscreen an element, unset element's -fullscreen flag and iframe fullscreen flag (if any), and -remove from the top layer immediately given element. +
To unfullscreen an element, unset element's fullscreen +flag, iframe fullscreen flag (if any), and keyboard lock flag, and remove from +the top layer immediately given element.
To unfullscreen a document, unfullscreen all elements, within document's @@ -177,7 +178,13 @@ steps:
These steps integrate with the event loop defined in HTML. [[!HTML]] +
All elements have an associated keyboard lock flag. Unless stated otherwise it +is unset. +
A document has keyboard lock active when its fullscreen element is not +null and the fullscreen element's keyboard lock flag is set, and inactive otherwise.
document . {{Document/fullscreenEnabled}}
Returns true if document has the ability to display elements fullscreen and fullscreen is supported, or false otherwise. @@ -392,6 +413,17 @@ are:
The order in which elements are fullscreened is not observable, because run the fullscreen steps is invoked in tree order. +
Depending on the value of options["{{FullscreenOptions/keyboardLock}}"]: + +
Set this's keyboard lock flag. + +
Unset this's keyboard lock flag. +
Resolve promise with undefined. @@ -506,7 +538,7 @@ could be an open <{dialog}> element.
Return promise, and run the remaining steps in parallel. -
Run the [=fully unlock the screen orientation steps=] with doc. +
Run the fully unlock the screen orientation steps with doc.
If resize is true, resize doc's viewport to its "normal" dimensions. @@ -595,6 +627,11 @@ algorithm as part of the close request steps. This takes precedence over
The user agent may end any fullscreen session without a close request or call to {{Document/exitFullscreen()}} whenever the user agent deems it necessary. +
Users should be clearly notified when keyboard locking is active, possibly through browser +UI indicators. + +
There should be a simple and intuitive method for users to override keyboard locking, reverting +control back to the system or user agent.
Keyboard locking enhances the functionality of web applications running in fullscreen by allowing +them to intercept certain key inputs that would typically be handled by either the system or the +user agent. This is useful in scenarios such as gaming or remote desktop applications, where keys +like ESC or function keys are integral to the application's functionality. + +
A keyboard lock 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 keyboard lock is active, or it could still have the same action but +allow the web page to call {{Event/preventDefault()}} to cancel the action. + +
Whenever a document's keyboard lock 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. + +
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. + +
For example, user agents that use the Esc key to exit fullscreen use keyboard lock to prevent +immediate exit on key press, and instead require a long press to exit fullscreen. Some such user +agents also implicitly grant partial keyboard lock to fullscreen session, in which case the Esc key +might be the only key that is affected by explicit keyboard lock. + +
This prevents e.g. content from third parties to go fullscreen without explicit permission. +
When applying a keyboard lock, only a limited set of keys, primarily those not involving +system control or privacy risks (like Alt+Tab, Ctrl+Alt+Del), can be locked via the API. + +
When applying a keyboard lock, user agents should implement safeguards to prevent abuse of +this feature, such as allowing users to override the lock. + +
User agents may provide a user preference to ignore keyboard lock (with any granularity, +e.g. for a specific site, or globally). Similarly, some platforms might not have a keyboard, where +user agents may ignore the keyboard lock state. However, this should not affect the +web-observable behavior of the {{Element/requestFullscreen()}} method or be exposed in other ways, +to avoid fingerprinting. +