Our selection handling regressed

[maltenuhn]

Problems 1: In a number of cases, you now need to click (instead of mouse down) to select; or cmd-click twice on the canvas to make a selection, even when the hover highlight is drawn correctly

• for instance: in this project https://utopia.pizza/p/32d228f0-lace-attic/ select the scene, then cmd-click on one of the pink rectangles

2) click-and-drag now frequently does not work (see https://monosnap.com/file/C5GmtoFz9WOyqnOmbCmT22ty9hRp1N)

Solution Notes We had quite fine-grained handling to cover on-canvas selection, including lots of edge cases (mouse-down-and-drag, cases where a click not a mouse down is required - in flex, if memory serves), and some of this was also refined when we introduced canvas strategies. If you find a solution that's deceptively easy, that probably only means it has regressed other behaviours other behaviours. Please talk about what you find, and the solutions you propose.

[seanparsons]

@maltenuhn

Slight correction, it's not so much the click per se, but the mouse up that triggers some selection (especially in the cmd modified version of that). That was definitely an intentional change at some point in history.

The getPreferredSelectionForEvent function is likely responsible for the change in behaviour relating to cmd-double-clicking which also prevents selection from changing when elements are overlapping.

Cmd-dragging explicitly protects against changing selection during the mouse up.

Questions:

• Do we want to operate with the axiom that whatever is highlighted will be selected on a mouse down (similarly for cmd mouse down)?
• Should we never change selection on mouse up?
• Should we have a way of locking selection from changing during an entire drag operation?