Orbit Controls Keyboard control focus

[rhairston]

Description of the problem

While looking at #9435 I went to test the fiddle against the current example http://threejs.org/examples/#misc_controls_orbit and found that, once you click outside of the container, specifically:

1. A header of the example sections on the side.
2. The view source button, then return back to the page

keyboard controls seem to stop working. This could be an html error or an orbital controls error. I will look into it.

Three.js version

• Dev
• r79
• ...

Browser

• All of them
• Chrome
• Firefox
• Internet Explorer

OS

• All of them
• Windows
• Linux
• Android
• IOS

[mrdoob]

This could be an html error or an orbital controls error. I will look into it.

Any findings?

[Mugen87]

I've looked into the issue today and i can only reproduce if the example runs inside an iFrame. Without an iFrame (https://threejs.org/examples/misc_controls_orbit.html) everything works fine. And i think I know why 😊

• Call https://threejs.org/examples/#misc_controls_orbit and use the arrow keys. Everything works fine so far.
• If you click on the side bar, arrow keys stop working since the inner window object (iFrame) lost focus. That's the reason why the arrow keys stop working.
• Because the mousedown event listener of OrbitControls calls event.preventDefault(), the inner window never gets focus again even if you click on it.

I don't think we can provide a reasonable fix for OrbitControls. IMO, this problem has to be managed on application level.

[WestLangley]

@Mugen87 Yes, there are too many use cases. Robustness sometimes must be handled at the application level. I think this can be closed.

[mrdoob]

How about adding if ( domElement instanceof HTMLElement ) domElement.focus() in the onMouseDown function?

[Mugen87]

Um, does not seem to have any effect. If i change the code to window.focus(); instead, arrow navigation works again. I guess it's because the keydown event listener is attached to window and not canvas.

Independently, this code would only solve the problem partially. If the users clicks outside the iFrame, arrow keys won't work after all. I'm not sure it makes sense to fix this in OrbitControls.

[mshamaseen]

Any update on this issue ??

[mshamaseen]

Ok i found a work around in a forum:

Problem solved. My issue ended up being two pronged:

I was triggering a browser security exception by using the absolute path to my website in the iframe (<iframe src="http://www.mysite.com/dir/index.html"></iframe> instead of the path relative from the domain root <iframe src="/dir/index.html"></iframe>
The other issue was the window variable that inputs were bound to needed to be set to the parent window when one was available (which there is in the case of an iframe). This small snippet fixed that

var realWindow = window.parent || window;//..... //Attach event listeners realWindow.addEventListener( "keydown", key.downHandler.bind(key), false ); realWindow.addEventListener( "keyup", key.upHandler.bind(key), false );

[mshamaseen]

@mrdoob ok I think I found a solution, in orbitControls line 939 ( in my case) change

window.addEventListener( 'keydown', onKeyDown, false );

to:

var realWindow = window.parent || window;

realWindow.addEventListener( 'keydown', onKeyDown, false );

This will make sure the event is assigned to the right window.

[mshamaseen]

@mrdoob In my project I added these codes also in onMouseDown function in orbitControls.js:

realDocument = parent.document || document;
realDocument.activeElement.blur();

because I have DOM input elements in the same iframe, if I change the focusing (using jquery) to input element, i can't get back to focusing the canvas element using mouse click, so this edit solve the issue.

[arodic]

keydown event listener is attached to window and not canvas.

I found this a bit problematic when using OrbitControls inside bigger applications, multiple viewports etc. Here I would suggest to add keyboard listeners on canvas instead.

However, it would also be necessary to enable focus on the canvas (to capture key events) and potentially adjust style for outline if you don't like how focused elements look by default.

Also considering #9435 I think all controls should have configurable keys to enable better compatibility with other tools like keyboard selection controls in this particular example.

To take it even further (sorry I don't mean to derail this discussion)... I think keyboard commands like "focus selected" should live in a separate controller outside OrbitControls.