MousDown is fired two times on mobile Devices

Hello,

i have overwritten MousDown/MouseMove/MouseUp on the WebViewer, to do additional things in that events. The code looks something like this:

    this.wvInstance.Tools.FreeHandCreateTool.prototype.mouseLeftDown = function(e) {
      console.log(e);
      console.log('down');
    }

    this.wvInstance.Tools.FreeHandCreateTool.prototype.mouseMove = function(e) {
      // console.log('move');
    }
    
    this.wvInstance.Tools.FreeHandCreateTool.prototype.mouseLeftUp = function(e) {
      // console.log('up');
    }

On Desktop this works good. But when i’m on a mobile Device (iPad for example), the MouseDown event is called two times. I figured out the following:

Short tap (tap on the screen and immediatly release): The MouseDown is fired two times (first: TouchEvent, second: MouseEvent).

Long tap (tap on the screen, hold for one or two seconds and release): Only the TouchEvent is fired (that’s the behavior i wan’t all the time).

Is there a way to get rid of the second “MouseEvent”? If not i must another way to “fix” it, but this is a little bit frustrating …

I tried WebViewer in Version 7.3.3 and also Version 8.0.0, the behavior occurs on both Versions.

Best Regards,

Chris

Hello, I’m Ron, an automated tech support bot :robot:

While you wait for one of our customer support representatives to get back to you, please check out some of these documentation pages:

Guides:APIs:Forums:

Hello Chris,

I took a look back at previous versions and it looks like this has always been the behavior, so it wasn’t something introduced in-between versions. I tested on Android as well:

What you can do is to use debouncing (with either setTimeout/clearTimeout or lodash.debounce) to ensure your code executes only once despite two triggers.

Hello Andy,

thank you for your answer. I will do so.
But what would be interesting to me: Is this behavior wanted?

Because as mentioned in my first post, if you touch and hold for 1 or 2 seconds only the touch-Event is fired.

Thank you!

Hi Chris,

It looks like these are the events emitted by the HTML viewer element. Thus, it is the browser that is emitting the events and WebViewer is just passing it on.

Andy Huang

Hello Andy,

thank you, this makes it a little bit clearer.

Chris