The puzzle probably turns single touch on for the drag - but on your tests... there is no singleTouch on the drag or in the Frame - so never mind.
Can you please test this and also tell us what you see in the console.
The stage should turn red when dragging and green when there is a pressup.
I live in Belgium like @karelrosseel82 , so was sleeping 
This is the console. The stage did become red on pressdown and ALWAYS becomes green now even when I do very fast drags over very small distances.
So it looks like the pressup fires ok now. In the console I do see a lot of downCheck: false and dragPaused false, Downcheck looks mostly false but can (as you see become multiple times true).
That is interesting - that is what I don't see on the PC. It does not say downCheck false. So we will dig to see why that might be. But at least we have found what it stopping the pressup event - we commented out the stopImmediatePropagation in that conditional.
1 Like
Okay - it looks like the only other place that the downCheck would get set to false is in the mouseupplus event which tracks for mouseups outside the stage. If this is for some reason being run before the normal pressup then it would be a problem. On the PC, it is being run after the normal pressup. Can you please show your console log for the same test file again. Do a refresh. Cheers.
Well - that's a little confusing. Can you drag it three times and that's it and show all the console. Thanks.
3 fast drags (I guess that nice round grey number 2 isn't our friend) ?
Can you do just three regular-speed drags.
This is what we get:
Three reds followed by three pinks. If the pink comes before the red - that is bad - although we can adjust it so it is not bad - but it is complex and we need to be a little careful.
This is normal drags, but these never gave me problems. Even not on 017. Ist were the quickies which don't work reliably on 017 and 016 and do on 015
Interesting... see the difference. For some reason, on fast drags, the order is out of order. The mouseplus triggers first for some reason. That messes it all up as it clears the drag test before the real pressup fires - and that was causing the real pressup to cancel any future pressup events. Okay. Thanks - that should be enough to go on.
You can give me a shout if you want something else to be tested.
1 Like
Okay - can you please test
https://zimjs.com/test8/drag.html
and then also perhaps test this TextureActive as well:
https://zimjs.com/test8/drag2.html
and a Scrambler - try releasing outside the canvas too - like outside the browser - or on the console.
Here are the results of drag and drag2 (in this order);
Drag 3 worked perfectly and didn't show anything in console, but the dragging worked even outside like you described
Can you test the first two links again and drag fast, but wait a couple seconds before each drag.
Also, just to confirm, is the red from the pressdown always being turned off on the pressup? So it never stays stuck on red?
Here are the consoles of drag and drag2 and I left 3 seconds between each drag-drop
on the parts where there are multiple downs without an up the red keeps red after the drag ends. I suppose thats because it doesn't detect the drag ending and therefore also doesn't execute the code to make it green again
So did it work twice okay for each and then on the last downs there were no ups and it remained red?
So, it seems we have not solved it. Where the heck are multiple downs coming from - there should be only one down. We will have to do a test then with all the stop propagations removed and see what is happening with just raw drag.
First, can you please test again - I changed pressdown to mousedown on the first two examples. Do a hard refresh. It should say mousedown and pressup now in the console. Again, wait a bit between each quick drag.