nsb13: rapid click/move/click sequence confuses the click/drag/d-click system a bit

[heppg]

New is a nice script editor problem, found it in hide/show scripts test or play sound/stop sound tests: had the blocks 'hide' (A) and 'show' (B) in script area and quickly tried to hit one after the other with the mouse to activate them. In between, it happened that I have hit one of the blocks (A), but the other used before (B) got 'connected to the mouse' and got dragged around, although the pointer was on another block (A). Also worked with (B), (A), and I observed this too for play sound, stop sound-blocks.

Looks as if you hit another block while the 'white border'-decoration still active, then there is some unrelated events. (test 49,50). And you need to be really fast in moving the mouse...

[timrowledge]

Actually this can happen with any block type, so I'll need to think of a better title for the issue. What is happening is that the first click a) does the click action for the block b) starts a little process that waits to see if there is another click of a >10 pixel move of the mouse within the 'double-click' time; if there is we conclude that either a drag or a d-click action is needed.

So by deliberately quickly clicking, moving, and clicking, you are convincing the system that you are doing a drag in a rather awkward way. Now, I set the double-click time out to quite a long time - 1000mSec - a while back to help with detecting d-clicks in the file open dialogue etc. I could reduce it somewhat but that might make a more common use pattern a bit more annoying.