Mouseup event does not work along with OrbitControls

Questions
, ,
1

In the example, clicking on the scene does not change the cube color because OrbitControls:

With no OrbitControls, it works:

How do we get the custom mouseup event to work along with OrbitControls?

1 Like
2

I almost found a solution, but it doesn’t quite work right:

Looking for a way to do it without forking Three.js code.

3

You can use pointerup event instead of mouseup (it will then work for both touch and mouse, just like orbit controls.) They do seem to interfere in some way - since OrbitControls does not have any direct mouseup listener.

May be a thing to report in github. :man_shrugging:

1 Like
4

I had a similar issue and had to comment out https://github.com/mrdoob/three.js/blob/c8226bfca0dd5571ad35f3257a888801856728e3/examples/jsm/controls/OrbitControls.js#L831 this line in order to not have it interfere, which means having my own copy around :S

5

Yeah, I see the OrbitControls code only uses pointer* events, and no mouse* events so it seems bizarre that it messes up the mouseup event. It is very weird.

Indeed I tried commenting out that same line, but mouseup is still not working after that.
It is very strange. I don’t see how pointer events interfere with the mouse events.

EDIT! Nevermind! It works with that line commented. I must’ve thought I commented it in my project and maybe it didn’t propagate into the build or something.

Here is the same example with a forked OrbitControls and the commented line:

6

It seems to me that libraries (f.e. Three.js, or any other library) should not be calling preventDefault on any events (because they are libraries) and they should allow application authors to choose the desired behavior (app authors can add their own event handlers that call event.preventDefault() for example, therefore opting into that behavior).

That’s how all libraries generally work. Three.js is the first library that I’ve used that (as far as how it operates with DOM events) calls event.preventDefault() and does not give the end user a way to opt out of that behavior.

The problem is there is no way to reverse an event.preventDefault() call, so an end user of such a library is stuck with one behavior that can not be modified (apart from forking the code).

In my humble opinion, it would be great for Three.js to either

  • not ever call preventDefault() and its documentation should tell users to add event handlers that call event.preventDefault() if they wish to disable certain browser behaviors (letting end users have control)
  • or provide an option to OrbitControls that can disable the calling of event.preventDefault() (letting end users have control).

I can’t think of a good reason to disable this browser feature without allowing app authors to control it.

1 Like
7

I gave it a try, and indeed that works (thanks!):

I can’t mark it as the solution because it doesn’t fix mouseup events. Ideally OrbitControls would give the user control over the behavior.

2 Likes
8

Looks like the following is the bug after the r120 update:

https://github.com/mrdoob/three.js/issues/20191 (@Mugen87)

They fixed it by migrating the examples to pointer events, but that didn’t solve the actual problem.

Just my $0.02, as mentioned above, ideally Three.js would either

  • never call preventDefault() and its documentation can tell users to add event handlers that call event.preventDefault() if they wish to disable certain browser behaviors that can not otherwise be re-enabled (letting end users have control)
  • or provide an option to OrbitControls that disables the calling of event.preventDefault() (letting end users have control).
9

@ilithya I saw you hearted my comment. I fixed up all the above examples, which were previously showing 404.