Disable ESC to automatically end requestPointerLock

[lachsen]

NWJS Version :0.65.1 Operating System : Windows

Expected behavior

Context: Game. After the pointer has been locked using requestPointerLock, the user presses the ESC key to open the game menu. The ESC key should be recognized via keyboard event and event.preventDefault() can be used to keep the PointerLock

Actual behavior

After requestPointerLock has been used, a following press of the ESC key is entirely ignored by keyboard events. There is no way to avoid the default behavior in that the pointer lock is always ended.

How to reproduce

1. requestPointerLock()
2. Press Esc
3. No Keyboard event is fired.

I understand that this behavior is desirable in a browser context to stop applications from permanently locking the user's pointer.

In NW.js, however, there HAS to be a way to disable this, so users can use the ESC button without being forced to escape the pointer lock state!

It should be noted that this issue didn't exist for older NW.js version (we used 0.35.5 before)

[lachsen]

Update: I also noticed that after each pointerLock has been ended, another one can't be started for another second. This is another security feature that should be disabled for NW.js if possible.

[ayushmanchhabra]

Just read up on the Pointer Lock API and played around with the demo to get an understanding. To make sure I understand, do you want to use the Esc key for calling a function other than exitPointerLock by calling event.preventDefault before it?

[ayushmanchhabra]

Closing this since there hasn't been any movement/progress made. Ping me here if you have any more Pointer Lock related queries.

[lachsen]

Hey! Sorry, I didn't see the response to this issue.

@ayushmxn

So yes, what you describe is pretty much what I want. Currently, it seem like no keyboard event is fired when:

1. The pointer lock API is active AND
2. The ESC key is pressed.

Instead, the pointer lock is always cancelled. Additionally, a delay is started within which no further Pointer Lock can be started.

As I mentioned: I understand why this feature was added. In the context of the brower, you want to avoid the possibility of a WebApp locking the player into a tab with no way to escape via Mouse Controls.

However, in the context of desktop application / game, where the player should be able to use the ESC key for various actions (such as opening pause menu, escaping prompts etc.), this behavior really isn't desirably. You essentially lose control where you can use the Pointer Lock API and where you can't - or you simply can't use the ESC Key.

In my opinion, this situation is similar to the various limitations that have been added to the WebAudio API over time. In the Browser you cannot simply play audio in a tab. The user first needs to interact with the webpage/web element for it to be able to play audio at all. Again, this limitation was added to avoid annoying WebApp behavior within the browser. However, this behavior is (fortunately) disabled in NW.js so you can play sounds before the user interacts with the window - like a title theme when the game starts.

So my ideal solution would be to simply disable those two limitations of the Pointer Lock API for NW.js:

1. Don't stop the Pointer Lock by default when ESC is pressed (or allow the app to cancel the default behavior via event.preventDefault - the way it used to be in older NW.js versions)
2. Don't add a time delay after the pointer lock was cancelled within which no new pointer lock can be started

Anyway, thanks a lot for responding! It would be amazing if this issue can be tackled in any way. Even just reducing the time delay would help a lot.