@martinthomson @smaug----

Not necessarily an issue that blocks support; but in glancing over the description of the intended feature, it requires that the site in question be full-screen as a predicate for requesting access to the system keys. Presumably this is done as part of the security story (although I don't see any treatment of the assumed threats in the explainer). Without having given a lot of time thinking about the attacks that this aspect of the solution is intended to address: if this is part of the security story, then the proposal needs more text to talk about interactions with other open applications in multi-monitor configurations (where the browser is full-screen in only one of several monitors).

This seems like a broadly reasonable feature to me. The lack of spec is not a big deal, but there are a few things that would need to be worked through, like the permission model.

I would caution that holding ESC is probably insufficient a signal. Repeatedly striking the key should probably have the same effect. The notice that is shown in the examples is too similar to the notice we show for regular fullscreen access, so the special status might be hard to discern. It seems like we should try to be generous in our interpretation of any signal like that.

If @adamroach's question has a reasonable answer, then I would suggest that this is instead an addition to the fullscreen API rather than a separate API.

Passing a set of keys to capture seems like it overcomplicates the API. A simple boolean should suffice. Then we don't have odd situations where Alt-Tab is captured in some cases and not others. Consistency in user experience suggests that this would benefit from simplification.

No mention in the explainer about the Windows Key. Where there is a "system" key like that, we should probably also exit fullscreen and end the keylock. I realize that this could make game developers unhappy, as disabling that key is now a regular feature in games, but it might be used to spoof a system take-over by drive-by sites, at the low, low cost of a mouse click or keypress.

It seems like there's a v2 proposal that we should probably take a look at (if that wasn't what we were looking at before).

cc @smaug---- @EdgarChen @masayuki-nakano

I just had a look at the v2 version of this. It looks the same as the old one in all ways that matter.

I still don't understand why this needs to be able to pick and choose keys. That way lies inconsistency and exploitation. Let's say that a site grabs a subset of keys. Now I become acclimatized to using a key combo that isn't captured (e.g., ctrl-w to close the tab). The site can subsequently change its mind and then hijack that interaction.

It is also harder to communicate about what has happened if there are multiple options. The API still contemplates capturing system keys with no special consideration given.

Finally, though this is the domain of individual browser UX, communicating about what is happening needs more consideration in the design. In Firefox, we have an overlay that appears after the transition to fullscreen for this purpose. That explains what happens and what you can do as a user to correct it, which are critical accountability measures. For this API, you might imagine showing an additional icon on that notification when keys are locked. In this case, we have a separate API, so the fullscreen transition might happen without locked keys, and we lose the ability to control that transition. Showing a notification overlay when locking happens is maybe possible, but that is less good as you now have two transitions and notifications to concern yourself with. Having ambiguity in what keys are captured makes it worse.

As the new proposal doesn't really address these UX concerns, I don't think that this is ready to evaluate.

The ability to pick and choose keys causes also a possible web compat issue, when some UA A hasn't reserved some key but some other UA B has and web dev tests only on A. Easy to forget to lock all the keys needed.

It seems to be also unclear how key lock should work on editing areas, like <input>. Chrome impl doesn't seem to prevent relevant default actions. Should it?

Here's a sketch of an alternative that I believe addresses the concerns raised here. It also has the advantage of being a modest-sized pull request on the Fullscreen API rather than a full-sized specification.

I don't have a good sense about how to manage <input>, but it seems like it shouldn't be intractable. One model to use is that there is a default handler for key events that a site can receive and maybe intercept. With that model, adding the ability to both receive and block events for keys that would otherwise be browser-managed is simple. That would not necessarily break <input> if consistently applied. Indeed, <input> would still work up until keys that were necessary for proper function being intercepted.

The current structure of Section 3.2 of the proposal is a little bit vague regarding how events are handled. It seems to imply that the API causes the event to be delivered AND the default action prevented. This is not consistent with other key events.

I think we should publish our position (#353) and file a bug over on the Keyboard Lock repo with the alternative. Then we can pick up the conversation there.

Keyboard Lock API is included in Chrome now: https://caniuse.com/mdn-api_keyboard_lock

Will it appear in Firefox as well?

We indicated the proposed API was harmful, though we think the usecase is reasonable. My cursory scan of the current API it appears that the issues we raised have not been addressed. In fact, checking the issue tracker, it looks like no real work has been done (and hardly any comments) to any of the issues filed against this over 3 years ago. It has the appearance of a post-facto spec thrown over the wall after an implementation was done, and then dropped.

Just two little things... just to avoid confusion, would you mind removing my username from the OP? (though always a Mozillian at heart ❤️)

We are working on a WebKit Position for this: WebKit/standards-positions#182

I think we reached the same conclusions reached here. I think we all acknowledge the use case and it would be interesting to expand on the aforementioned proposal.

@martinthomson, or other folks, could you bring that to the WICG and maybe we can work on it together with the webkit community? It seems to address a lot of the concerns and it's in line with similar proposals, for example: whatwg/fullscreen#207

I can't commit to the time necessary to drive that proposal, but I will ask around to see if anyone else at Mozilla is interested.

That's ok. We can also try to find someone to drive it on the WebKit side. The main thing would be having it as a contribution on the WICG side for IPR reasons.

I'm happy to formally make the contribution to any W3C group if that would help your IPR concerns. It seems like fullscreen was moved to WHATWG. Would their IPR policy be sufficient? It seems like working over there would be the ideal outcome for something that is relatively small like this.

See whatwg/fullscreen#231

See https://textslashplain.com/2023/09/12/attack-techniques-fullscreen-abuse/ for an attack vector with fullscreen and keyboard lock.