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.

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.

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.

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.

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.)

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.)

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?

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?

Since Safari has shipped, the cost of tweaking the API is higher now. I think we should keep the "none" and "browser" enums, but drop "system".

It should be up to the UA to decide which keys are reserved with keyboard lock active (and when not active).

Adding Gecko as interested implementer (see https://bugzilla.mozilla.org/show_bug.cgi?id=700123).

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.

It's possible to feature-check that the keyboardLock dictionary member is supported without going fullscreen like this: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/14660

This doesn't tell you whether a particular value is supported until actually going fullscreen, though. This step:

If FullscreenOptions 's keyboardLock 's value is not supported, reject promise with a NotSupportedError exception and terminate these steps.

Runs after rejecting when |error| is true, so you can only tell that the value is supported by going fullscreen with requesting keyboardLock (and checking that the dictionary member is supported first, since unknown dictionary members are silently ignored).

While this method of checking dictionary members has been deemed sufficient for feature-checking in some cases, I could be convinced that it's not ideal DX and there should be a property similar to document.fullscreenEnabled (e.g. document.keyboardLockEnabled) to allow easy feature-checking and easy checking if keyboard lock is currently active. (If we drop system then this becomes a boolean.)

How should this interact with the navigator.keyboard.lock() API?

I noticed a problem and am wondering about the more general idea with nested fullscreen scenarios. In both "requestFullscreen(options) method steps" and the "exit fullscreen" algorithm, the flag is only set/unset on a single element. But in nested scenarios, there's no guarantee that those elements are the same. Consider this simple case:

elm1.onclick = () => { elm1.requestFullscreen({ keyboardLock: "browser" }); }
elm2.onclick = () => { elm2.requestFullscreen(); }

If the elements are clicked in order and later something triggers "fully exit fullscreen", the keyboard lock flag will remain set on elm1.

No it won't, because fully exit fullscreen calls #unfullscreen-an-element on all fullscreened elements which unsets the keyboard lock flag.

It's true that "exit fullscreen" for elm2 in your example will change the fullscreen element to elm1 and then keyboard lock is active again; this is intentional.

How should this interact with the navigator.keyboard.lock() API?

For Gecko, the plan is to not support that API.

Can someone prepare the WPT PR so we can merge spec and tests together?

@marcoscaceres WDYT about interaction with the keyboard lock API for browsers that support both?

Can someone prepare the WPT PR so we can merge spec and tests together?

As listed in the OP, it already exists.

@foolip does Google have thoughts about usefulness of this API? One of my concerns is that, given browser shortcuts are already locked on fullscreen without keyboard lock on Safari and Chrome, people will not care about this API unless they care about Escape key behavior.

Edit: And the same question also applies to Blink's navigator.keyboard.lock, to me the API looks much less useful now compared to when it was introduced, because of the same reasons above.

Can someone prepare the WPT PR so we can merge spec and tests together?

As listed in the OP, it already exists.

Yes, but "PR for to move to non-tentative TODO"

@foolip does Google have thoughts about usefulness of this API? One of my concerns is that, given browser shortcuts are already locked on fullscreen without keyboard lock on Safari and Chrome, people will not care about this API unless they care about Escape key behavior.

Edit: And the same question also applies to Blink's navigator.keyboard.lock, to me the API looks much less useful now compared to when it was introduced, because of the same reasons above.

I'm reviewing this as spec editor and am not planning to implement anything myself, so no implementer interest from Google. But that isn't needed process wise since Apple and Mozilla do want this change.

That being said, given how "declarative" this API is I think it should be possible to define it in terms of the keyboard lock API later if we want to do that, or at the very least define how they interact. But to figure that out really requires an attempt to implement this, I think.

Can someone prepare the WPT PR so we can merge spec and tests together?

Done.

I think this is ready to land. CI checks are green now also.