Three.js: Pointer lock controls error unlocking

Created on 13 Sep 2020  路  8Comments  路  Source: mrdoob/three.js

Description of the problem

Pointer lock controls on the examples page throw an error after activating pointer lock, deactivating pointer lock, and reactivating pinter lock. This can cause the camera to also jump around to a random location.

To reproduce:
1) Click on the text saying 'Click To Play'
2) Press 'escape' on your keyboard to unlock the controls
3) Click on any part of the page other than 'Click To Play'

THREE.PointerLockControls: Unable to use Pointer Lock API

Three.js version
  • [x] r120

    Browser
  • [x] All of them

Browser Issue

Most helpful comment

This is now the leading issue at the Chromium bug tracker:

https://bugs.chromium.org/p/chromium/issues/detail?id=1127223

Since the current Chromium implementation is quite annoying for users, I would appreciate if everyone could upvote/star the issue in order to give it a higher priority 馃槆 .

All 8 comments

This seems to be a Chrome issue. Firefox and Safari work as expected (at least on macOS).

The following (non-three.js) Pointer Lock demo shows that the second lock does only work after some attempts similar to the three.js demo. https://mdn.github.io/dom-examples/pointer-lock/

Do you mind reporting this to the Chromium bug tracker? https://bugs.chromium.org/p/chromium/issues/list

@Mugen87 thanks for catching the bug in chrome. I submitted the bug here https://bugs.chromium.org/p/chromium/issues/detail?id=1127920. Hopefully, we'll hear back soon.

Did Arodic's solution end up fixing the camera position jump?

Did Arodic's solution end up fixing the camera position jump?

Yes. 馃帀

This is now the leading issue at the Chromium bug tracker:

https://bugs.chromium.org/p/chromium/issues/detail?id=1127223

Since the current Chromium implementation is quite annoying for users, I would appreciate if everyone could upvote/star the issue in order to give it a higher priority 馃槆 .

Stumbled on to this issue as well. Calling the lock/unlock api directly does not seem to result in this error, only when using the 'esc' key to exit (and quickly trying to activate it again). So for now I will hide the reactivate-button for some seconds if I detect a esc-keypress when leaving fps-camera-mode.

So for now I will hide the reactivate-button for some seconds if I detect a esc-keypress when leaving fps-camera-mode.

Unfortunately, this workaround does not always work. Think of a game where players quickly want to change between in-game and menu view. The current behavior in Chrome more or less breaks such use cases.

True. Hopefully they will fix it. But meanwhile, could you use a different key to activate the menu and call unlock() yourself? Maybe not an option for you though.

The Chromium bug is now marked as fixed although the lock/unlock issue is not fully mitigated. The browser just decreased the time frame in which a unlock/lock is considered to be invalid. It's now 1.25 seconds instead of 2. I've mentioned at bugs.chromium.org that this solution is not satisfying however I'm not sure if the security policy will be reconsidered. If you are also affected by this issue, please request at the following site for a change:

https://bugs.chromium.org/p/chromium/issues/detail?id=1127223

Was this page helpful?
0 / 5 - 0 ratings

Related issues

clawconduce picture clawconduce  路  3Comments

boyravikumar picture boyravikumar  路  3Comments

zsitro picture zsitro  路  3Comments

yqrashawn picture yqrashawn  路  3Comments

Horray picture Horray  路  3Comments