Selected block not cleared after dragging a block

[brassaro]

Expected Behavior

After dragging a block (either from the flyout or on the workspace), the 'selected' block (Blockly.selected) should be cleared. This means that clearing the 'selected' block should be done on mouse up.
Using this, every time a block is picked up on, an 'ui' event is created and can be acted upon.

Actual Behavior

After dragging a block, the 'selected' block is not cleared. The value of Blockly.selected is still the last block dragged, until a new block is selected or a mouse down event happens.
Currently, since the 'selected' block is not cleared, when dragging a block for the 2nd time in a row (without interacting with anything else in the meantime), no 'ui' event is created, and so it is not as easy as it should to detect that this block was picked up.

Steps to Reproduce

1. Launch tests/vertical_playground.html in your browser
2. Enable Log Events option
3. Drag a block from the flyout to the workspace
4. Notice that 3 events are logged: "Create" (when the dragged block is created); "Ui" (when this new block is selected); "Move" (when the block is set on the workspace)
5. Without clicking anywhere else first, drag the block again from the workspace to some other position on the workspace
6. Notice that only a "Move" event is logged, while we would except a "Ui" event first

Operating System and Browser

Mac OS 10.11.6 Chrome 58.0.3029.110 (64-bit)

[chrisgarrity]

@rachel-fenichel is this due to the dragging refactor?

[rachel-fenichel]

No, this is deliberate. The most recently touched block remains selected after you finish dragging it. Changing that would need to be an explicit decision by scratch team.

[MichaelZawadzki]

May I ask what is the logic behind this? Curious since it seems a little strange conceptually.

Also, we patched this on our end by unselecting the block on release. Can you think of any dangers this may introduce if the code relies on this? Note we haven't pulled in the large drag-n-drop changes but will be doing this soon (next week).

[rachel-fenichel]

It's the same behaviour as you get when you drag files around on your desktop or in a file explorer generally. Clicking on an item selects it and it stays selected until something else is selected or the selection is explicitly removed (by clicking on the background, for instance). Dragging does the same thing.

I'm not sure what to say about the conceptual strangeness--to me it feels completely natural, and to you it obviously doesn't. Maybe some programs implement it one way and the others implement it the other, so there's no default behaviour?

I don't strongly object to scratch-blocks changing it, I just wanted it to be clear that this isn't an accidental regression.

I don't think the code relies on the previous block being selected or not, so your patch should be fine.

[MichaelZawadzki]

Thanks for the explanation!

I had to play with my desktop for a second but I totally see what you mean, and indeed in this context it makes perfect sense ;)

In scratch + scratch-blocks once the block is released there is no special visual indication that it is still selected. This makes sense since there is no special action you can take on it (while on your desktop some hotkeys can allow you to rename this selected file). So this notion of "selected" is not really present for the user in scratch. Thanks for confirming that the code doesn't rely on this "selection" for anything. Indeed we haven't seen any problems with it.