OrbitControls: Removed tabIndex side effect.

[mrdoob]

Description

Changing the page's tabIndex when constructing OrbitControls was definitely not the right thing to do.

This also solves the problem of outlines showing in recent versions of Chrome when using OrbitControls.

[Mugen87]

It seems this breaks the key controls. Previously, it was possible to use the keys when clicking on the canvas:

https://raw.githack.com/mrdoob/three.js/dev/examples/misc_controls_orbit.html
https://threejs.org/examples/misc_controls_orbit

One way to solve this is to bind the keydown event listener to window. However, all key events will then be captured by the controls which was the original motivation for introducing tabIndex manipulation, see #16676.

[mrdoob]

@Mugen87 What do you think of this kind of API for controls?

const controls = new OrbitControls( camera );
controls.listenPointerEvents( renderer.domElement );
controls.listenKeyboardEvents( window );

[Mugen87]

Would it be necessary to call listenPointerEvents() each time OrbitControls is created?

As an alternative to new methods it would be also possible to introduce a third (optional) ctor parameter:

const controls = new OrbitControls( camera, renderer.domElement, window );

[arodic]

Changing the page's tabIndex when constructing OrbitControls was definitely not the right thing to do.

I'm wondering what made you realize that @mrdoob? Would it make any difference if the user was expected to set tabindex manually?

[mrdoob]

I'm wondering what made you realize that @mrdoob? Would it make any difference if the user was expected to set tabindex manually?

It's about the accessibility outline that Chrome started showing recently when the element has been tabbed into. One option was hiding the line (bad for accessibility), another option was removing this "auto tab" and let developers do it themselves when needed (opt in).

[mrdoob]

Would it be necessary to call listenPointerEvents() each time OrbitControls is created?

Yep!