Add keyboard locking option by marcoscaceres · Pull Request #232 · whatwg/fullscreen

marcoscaceres · 2023-12-06T07:28:46Z

Addresses #231

At least two implementers are interested (and none opposed):
- WebKit
- …
Tests are written and can be reviewed and commented upon at:
- …
Implementation bugs are filed:
- Chromium: …
- Gecko: …
- WebKit: …
MDN issue is filed: …
The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

Preview | Diff

fullscreen.bs

martinthomson

Pretty good. Some suggestions.

fullscreen.bs

martinthomson · 2023-12-06T21:39:45Z

fullscreen.bs

+<p>Users should be clearly notified when [=keyboard locking=] is active, possibly through browser
+UI indicators.
+
+<p>There should be a simple and intuitive method for users to override keyboard locking, reverting


It would be really nice if we could standardize this. That way, the experience is consistent across browsers.

I don't regard this as essential, but it would be nice.

Agree... though this might need to happen after browsers ship something and if we all align. I guess it would be a SHOULD (or even MAY) level thing. History suggests that we will naturally converge on a UI/UX convention for this.

Co-authored-by: Martin Thomson <mt@lowentropy.net>

mdevaev · 2025-11-27T02:05:11Z

Hello. Please forgive me for impudently and unceremoniously barging in :)

WebKit has recently received an implementation of Mozilla's proposal, and apparently at some point it will reach Safari and other browsers: https://bugs.webkit.org/show_bug.cgi?id=264843

As a developer of a web-based for remote access device, I'm super-interested in this feature because it's the only blocker that prevents me from recommending Firefox instead of Chrome to my clients.

I hope that if this specification is adopted, then eventually things will get off the ground, and it will be done in Firefox too. Considering that we already have an actual implementation, and if there are no problems here, is it worth merging this PR? It looks great.

lukewarlow · 2025-12-20T13:37:35Z

Per https://webkit.org/blog/17674/release-notes-for-safari-technology-preview-234/ I believe this has shipped in Safari TP. It would be good to check how accurate the spec PR is compared to the implementation and try to get it across the line now there's some implementation interest.

marcoscaceres · 2026-01-19T06:56:55Z

Ok, had a look. the WebKit PR does follow the spec. The only thing is that the tests that were added use WebKit infrastructure, but I think they could be migrated to be fullscreen tests... assuming we can lock and we all generally agree that hitting "ESC" once shouldn't cause fullscreen to cancel if the lock if applied (this might be hard to test across UAs... but we can try).

In the meantime we need interest from a second implementer.

mdevaev · 2026-01-19T08:01:23Z

As a developer, I would like to note that there is exactly one problem with the current draft/implementation: it is impossible to check the presence or absence of keyboardLock support on the target browser without having to call requestFullscreen(). There is no any flag or property that we could use for this. And even after the call, the code does not know whether it intercepts all key events.

If this is not supported, it would be great to be able to distinguish between these states to alert the user who expects all his keys to be intercepted.

It might not be too late to add something for that.

saschanaz · 2026-02-02T12:45:09Z

fullscreen.bs

+  "none",
+  "system"
+};
+


This is not what STP is shipping now, are we going to update this or is WebKit going to change?

saschanaz · 2026-02-02T12:46:53Z

fullscreen.bs

+  <dt><dfn>System-level keyboard lock</dfn></dt>
+  <dd><p>Capture a wider range of keys, including those used for system-level navigation and
+  shortcuts (e.g., Alt+Tab), subject to user consent and user agent implementation.


I think STP is not doing this (I don't see any non-browser shortcut is being captured), do we need this in that case?

Also, can environments like Linux snap/flatpak or Windows sandboxed MSIX support this? Sounds like we would surprisingly expose browser sandbox status if not.

saschanaz

based on above.

saschanaz · 2026-02-17T13:48:49Z

I'm concerned that Safari would ship with something nobody agreed on, without an updated PR. If @marcoscaceres is busy I can take this and update it. (In that case I'll exclude system lock mode.)

saschanaz · 2026-02-17T13:49:51Z

fullscreen.bs

+};
+
 dictionary FullscreenOptions {
+  FullscreenKeyboardLock keyboardLock = "none";


But do we need "none"? Maybe undefined can serve that purpose?

Maybe... what I like about "none" is that it's explicit about "no lock is applied"... vs undefined, which, yes, could mean "no lock is applied", but also means "undefined behavior (and potentially the browser is applying UA specific behavior)".

My question is, which one do we want? These are subtle, but important differences IMO,

But keyboardLock: undefined behaves exactly like "none" already?

saschanaz · 2026-02-23T17:21:47Z

I'm starting to think that all we need for keyboardLock: "browser" is to make the escape key not immediately escape fullscreen. Do we even need to call it "keyboard lock" in that case?

(Because browser shortcuts are already preventDefault-able.)

martinthomson · 2026-02-23T21:31:56Z

Are you suggesting that sites looking to avoid things like tab switching have some enumeration of all browser shortcuts and just .preventDefault() on all of them? Isn't there at least some value in having that done for them?

saschanaz · 2026-02-23T21:53:03Z

Are you suggesting that sites looking to avoid things like tab switching have some enumeration of all browser shortcuts and just .preventDefault() on all of them? Isn't there at least some value in having that done for them?

(TIL Firefox and Chrome even allow that...)

But anyway that's what Safari is going to ship now - there's no "bypass" as this PR says, all it does is to prevent the escape key to not immediately escape the fullscreen mode. There's no even extra capture for shortcuts, it turns out that both Safari and Chrome already allow the page to capture extra browser shortcuts on fullscreen mode that Firefox currently does not.

And I do think it may indeed be easier to just prevent-default those shortcuts in keyboard lock mode, but I'm not sure preventing all shortcuts is a great idea. Is Control+C a browser shortcut to prevent, for example? What is the definition of "browser shortcuts that we want to prevent" here?

marcoscaceres added 2 commits December 6, 2023 18:26

Add keyboard locking option

39ccb2f

Bikeshed fixes

2abdfda

marcoscaceres mentioned this pull request Dec 6, 2023

Keyboard lock #231

Open

marcoscaceres commented Dec 6, 2023

View reviewed changes

fullscreen.bs Outdated Show resolved Hide resolved

Update fullscreen.bs

72f9326

marcoscaceres commented Dec 6, 2023

View reviewed changes

fullscreen.bs Outdated Show resolved Hide resolved

Update fullscreen.bs

fee721d

marcoscaceres commented Dec 6, 2023

View reviewed changes

fullscreen.bs Outdated Show resolved Hide resolved

Update fullscreen.bs

0087119

martinthomson reviewed Dec 6, 2023

View reviewed changes

Apply suggestions from code review

f670402

Co-authored-by: Martin Thomson <mt@lowentropy.net>

marcoscaceres marked this pull request as ready for review January 19, 2026 05:41

saschanaz reviewed Feb 2, 2026

View reviewed changes

saschanaz suggested changes Feb 11, 2026

View reviewed changes

saschanaz reviewed Feb 17, 2026

View reviewed changes

Conversation

marcoscaceres commented Dec 6, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

martinthomson left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

martinthomson Dec 6, 2023

Choose a reason for hiding this comment

Uh oh!

marcoscaceres Dec 8, 2023

Choose a reason for hiding this comment

Uh oh!

mdevaev commented Nov 27, 2025

Uh oh!

lukewarlow commented Dec 20, 2025

Uh oh!

marcoscaceres commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mdevaev commented Jan 19, 2026

Uh oh!

saschanaz Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

saschanaz Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

saschanaz left a comment

Choose a reason for hiding this comment

Uh oh!

saschanaz commented Feb 17, 2026

Uh oh!

saschanaz Feb 17, 2026

Choose a reason for hiding this comment

Uh oh!

marcoscaceres Mar 2, 2026

Choose a reason for hiding this comment

Uh oh!

saschanaz Mar 9, 2026

Choose a reason for hiding this comment

Uh oh!

saschanaz commented Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

martinthomson commented Feb 23, 2026

Uh oh!

saschanaz commented Feb 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

5 participants

marcoscaceres commented Dec 6, 2023 •

edited

Loading

marcoscaceres commented Jan 19, 2026 •

edited

Loading

saschanaz Feb 2, 2026 •

edited

Loading

saschanaz commented Feb 23, 2026 •

edited

Loading