OrbitControls eats cursor movement keyboard events for other input fields

[kkolinko]

Description of the problem

OrbitControls registers a listener for keydown events on a window and processes the events regardless of which input element has focus. When a user uses keyboard to move cursor in an input field, the events for the left and right arrow keys of keyboard are handled by OrbitControls and do not move the cursor. Better behaviour would be to ignore the event if some other input element has the focus.

Steps to reproduce, using current dev branch and examples:

1. Open documentation (docs\index.html) and navigate to TorusGeometry document.
2. In the iframe that displays an example of a torus, click on "THREE.TorusGeometry" button to open a properties editor for the object.
3. Click on one of input boxes in the properties editor, e,g, on the value "10" for radius.
4. Try to use your keyboard to move cursor position to the left and to the right in the input field.
   Expected behaviour: the cursor moves, as you press left or right arrows on your keyboard.
   Actual behaviour: the image of the torus moves.

The behaviour of r101 is to suppress all keydown events, regardless of key code (known as #15810, already fixed in dev). The behaviour of r100 was to move both the cursor and the object.

This issue could be fixed by either a) registering the keydown listener on the domElement instead of a window, b) filtering the event according to the actual value of document.activeElement. The "b)" way seems to provide better compatibility with older versions of three.js.

Three.js version

• Dev
• r101

Browser

• Chrome
• Firefox

OS

• Windows

[Mugen87]

The former behavior of OrbitControls was changed because of #15619. The original PR introduced a problem since it prevents the usage of any keys when OrbitControls was active. #15693 fixed this issue by preventing the default action of a key press only for used keys.

I think we should keep the current behavior of OrbitControls. The perfect solution that makes everybody happy and also has a clean implementation without hacks is obviously not possible. Any modifications in context of key input should be done on application level.

[kkolinko]

Any modifications in context of key input should be done on application level.

Nice to have, but it means that an application has to either call the existing methods used in this feature, or have to re-implement them. The current handleKeyDown() method, or the pan() method that is called by it, are not public API. (The pan() method is non trivial, and calls other non-public methods).

[Mugen87]

Nice to have, but it means that an application has to either call the existing methods used in this feature, or have to re-implement them.

TBH, I don't understand the relation of this to the actual title of your issue.

In any event, it was already discussed that methods like pan(), rotate() or dolly() should not be exposed, see #9005.

Can you please demonstrate why is it hard to expose these methods?

[roprea]

@Mugen87 you say that those methods should not be exposed and then you ask him to demonstrate why it is hard to expose them. I am really confused about your comment and I totally agree with @kkolinko. I don't want to have to expose or do anything with those methods, just take the orbit controls file and use it as it is in order to easily update it when needed.

From my point of view it is a very bad user experience to be inside an input field and don't be able to use the arrow keys to go a character to the left or right just because you also have a small Threejs scene rendered inside the page. There are many other cases when you need the arrow keys and you are not able to use them at all, the input field was just a basic example.

Currently I am using an older version of Orbit controls just to avoid this new behavior and if possible I would like to be able to use the latest versions, so I totally agree with @kkolinko and vote for fixing the current/new behavior.

[Mugen87]

you say that those methods should not be exposed and then you ask him to demonstrate why it is hard to expose them.

@roprea If you would carefully read #9005, then you would understand why the methods are no part of the public API (espeically #9005 (comment)). It's not hard to expose these methods if you need them. I just wanted to know of @kkolinko why he thinks its difficult.

[roprea]

I have read it and as I previously said I totally agree that those methods should not be part of the public API and they are not hard to expose but I am totally against exposing them or making any custom changes to the Orbit controls. It just seems wrong to have to always expose them and create custom event handlers just to avoid this new behavior (which is blocking the arrow keys for the entire application) and doesn't allow the users to use the arrow keys for navigation, selections, going to the next slide/picture or other application interactions which are outside the ThreeJS container.

[Mugen87]

Closing in favor of #16597

[EliasHasle]

The former behavior of OrbitControls was changed because of #15619. The original PR introduced a problem since it prevents the usage of any keys when OrbitControls was active. #15693 fixed this issue by preventing the default action of a key press only for used keys.

I think we should keep the current behavior of OrbitControls. The perfect solution that makes everybody happy and also has a clean implementation without hacks is obviously not possible. Any modifications in context of key input should be done on application level.

#15619 was solved by #15620, right? So maybe the perfect solution is within reach with #16676 ?