Should not release pointer lock when pressing esc while fullscreen keyboard lock is active

[zcorpan]

https://w3c.github.io/pointerlock/#security says

Esc key should exit pointer lock with the user agent's pointer-lock target.

whatwg/fullscreen#232 introduces a keyboard lock option for requestFullscreen(). Chromium supports a separate API for keyboard lock.

I think it makes sense to not release the pointer lock when pressing esc if keyboard lock is active. Otherwise, the user experience for games is not ideal (e.g. if pressing esc opens and closes the in-game menu).

[saschanaz]

Maybe nice to say something like "if on fullscreen, pointer lock exits when fullscreen exists instead of esc" or something like that.

[saschanaz]

Maybe having pointerLock on fullscreen options make more sense in that case, btw? See #85.

In TPAC 2025 people agreed that screen lock should be a fullscreen option, for example. (https://docs.google.com/document/d/1fOjXiGUFf_krkfYaWf5drbqzY7CTxn7EcDYr5ZWjzFg/edit?tab=t.cnzoci72snh, whatwg/fullscreen#186)

cc @marcoscaceres

[zcorpan]

whatwg/fullscreen#186 is about orientation lock.

Pointer lock currently works without fullscreen. In any case, it's a separate issue.

[saschanaz]

It's not separate issue if the issue is that "there's a use case that fullscreen and pointer lock is expected to have the same lifecycle", no?

There can also be cases that pointer lock is not expected to have the same lifecycle - tapping esc is expected to escape only from pointer lock, e.g. if the lock does not cover the whole fullscreen page but intended to apply to a subset of the fullscreen page.

[mustaqahmed]

There can also be cases that pointer lock is not expected to have the same lifecycle - tapping esc is expected to escape only from pointer lock, e.g. if the lock does not cover the whole fullscreen page but intended to apply to a subset of the fullscreen page.

Yes, I remember seeing a drawing app where pointerlock covers the drawing canvas, and the drawing tools are always visible on a side (which are accessible only after exiting the pointer lock). So making "long-press to exit pointerlock" conditional on active keyboard lock makes perfect sense to me.

[scheib]

I agree with not existing when keyboard lock is active; keyboard lock should take precedence over ESC to exit pointer lock.
I am original pointer lock spec author.

[zcorpan]

There can also be cases that pointer lock is not expected to have the same lifecycle - tapping esc is expected to escape only from pointer lock, e.g. if the lock does not cover the whole fullscreen page but intended to apply to a subset of the fullscreen page.

Yes. I suppose there are two options, if we want to support the use case of games where you want to keep the pointer lock until exiting fullscreen:

1. Still have a single Esc keypress exit pointer lock while keyboard lock is active, but allow preventDefault() to override. Longpress still exits fullscreen, keyboard lock, and pointer lock.
2. Make a single Esc keypress not exit pointer lock while keyboard lock is active. Longpress exits fullscreen, keyboard lock, and pointer lock. Apps that wish to exit only pointer lock when pressing Esc can do so with JS.

[mustaqahmed]

I would prefer the second option because it seems to match the Esc key behavior in the Fullscreen spec.

I noticed that the spec wording there also allows preventDefault() of the Esc key but I guess that's not what the major browsers allow today, right?

[scheib]

When in doubt, match Fullscreen for consistency. I also vote for number 2.