Click outside workspace during keyboard move causes stuck move

[microbit-matt-hillsdon]

1. Start a move of "draw circle"
2. Click outside the workspace/toolbox
3. Observe passive focus indicator
4. Fail to resume the move when focus is regained

Perhaps the move should confirm or abort (depending on what we agree elsewhere)?

[microbit-matt-hillsdon]

Tab back to the workspace is OK, but the click back (likely if you clicked away) is not, likely as it’s ignored during the “drag”.

[gonfunko]

Possibly related to RaspberryPiFoundation/blockly#8868

[RoboErikG]

Is there a desired behavior for this case? I suspect the right way to handle this would be to treat it as a cancelled drag, but then the question is whether to drop the block where it is or revert it to where the drag started.

[microbit-matt-hillsdon]

My inclination is to confirm rather than cancel. But I find it kinda hard to justify. I feel similarly about the behaviour I proposed on #437 which also suggests biasing to confirm for keyboard actions during a move, e.g. T, Enter, T or T, Enter, C.

Dragging with a mouse feels like an active process where the default, if I stop holding the mouse button, is to drop the block in the location indicated. I think that bias makes sense for keyboard drag too.

[RoboErikG]

That's my intuition as well from a visual perspective. I think it'll be easier to understand what happened if the block gets dropped where it is vs snapping back to where it was.