these multiple downs are not firing at the same time. Its because there are no UPS after the downs that you see them bundled in console
Okay - but in this one:
Did you do three drags in each? Three drags should not give that many downs. Or are you saying that each down was a start of a drag and the up only is being caught sometimes?
Yes each mousedown was a drag start and the up is only caught sometimes.
Below are the 2 examples with exactly 3 drags
I must say that I think I discovered when it does it the most (if not always).
If I click - drag - wait and then release while the mouse is NOT moving... works!
If I click-drag and then while moving release the mousebutton, then the drag stops... but I don't get the up event
Hopefully this one helps
1 Like
Ahh!!! Good - that might explain it. Perhaps the pressdrag also has a cancel as well... will test it out after lunch. Cheers.
2 Likes
Okay. Could you please test again https://zimjs.com/test8/drag.html as follows:
- Do a single drag, wait, mouseup. Send the console results.
Refresh page.
- Do a single drag, mouseup without stopping mouse movement. Send the console results.
Thanks - please screenshot them without the messages wrapping.
Sorry, we can't test here - I wonder if is that we do not have a mouse on our mac and are doing the touch pad.
Okay - so... the mouseupplus is triggering even before the final pressdrag. Not sure how that can happen but that gives us something to go on here. The inside is the thing that is stopping the event from passing to the outside pressup - the one in the app that is changing the color back. Okay digging into it more.
Can you please refresh the drag example and do the same test you did before. Thanks. We added a 50 ms delay on moseupplus - if this works, we will try another test with a 30 ms delay.
1
2
After that I tried the fast drag and release maybe 50 times quickly after eachother and the color returned to green every time.
Okay - one more time, Bart, with a 30ms delay. We occasionally use a 50ms delay in our code and it would be good if this triggered before any other 50ms delays.
1 (slow)
2 (quick release while moving)
Retried the quick about 50 times and always came back to green.
Aha - that proves it.
We have a mouseupplus event that is used to capture a pressup outside of an iframe or in the console. The mouseupplus looks at whether the actual left mousebutton was down and now is up. So we test in the window mousemove and mouseup - outside of CreateJS and ZIM. It looks like the fast release is triggering that the left button is up in a mousemove rather than only in a mouseup. This then is sooner than the actual pressup which was messing things up. Looks like adding a 30ms delay is solving it. Not the best solution but probably okay.
We recently found out as we were working on TextureActives that the pointerup event triggers even outside or on other iframes, etc. so that seems to be more reliable. I do not necessarily trust pointerup as in the past Apple has not supported things like that - go figure. But perhaps for ZIM 018, we will revisit this and do some testing on a pointerup solution. Although, a quick search right now led me to this which is not really promising.
Thanks for the testing, Bart - we will patch ZIM 017 with the 30ms delay.
Hey - figured out a solution:
If it is a mouseup that is triggering then dispatch right away else dispatch after 30ms.
The mouseup is on the bubbling phase (later) - whereas the actual pressup is on the capture phase (earlier). So that is why we were expecting the mouseupplus to come after the pressup allowing us to ignore it as we already had a pressup.
ok, so is this something that 017 will fix or will it be in 018? For the app I'm currently making I stick to 015 because it has all the features I need
No - it is about to be fixed in 017. We were just considering another way for 018. It should be working in 017 right now.
2 Likes