👎: Top-most object not selected on mouse down

[ Would like to continue conversation started here but that was locked (got busy!) so am re-posting. ]

If two objects overlap and the lower the current selection, a full click (mouse down and up) is required for selecting the top most object under the cursor, rather than a mouse down. This behavior is inconsistent from normal Figma selection behavior and other tools (Adobe XD, Illustrator, Sketch) fwiw.

@Avokadomos Replied:

This is intended so that you can move the selected layer by dragging anywhere within the bounds, even if it’s covered by other elements. The same happens in Photoshop if I drag a selected layer that is below another.

This is incorrect AFAIK — I just opened a fresh install of PS 2022 with default settings and a mouse down selects the top most layer with opaque pixels under it regardless of what the current selection is at the time of mouse down.

And regardless, as stated, Illustrator, Sketch, and XD do not behave this way, so the question just becomes ‘why should Figma behave like Photoshop and not like other more contemporary vector and UI tools’?

Basically, mouse-down-to-select-item is a building lock idiom and it’s being broken for one niche situation to save steps and it’s being broken in a way that effects much more common use.

Moreover, the edge case has an even narrower edge case where the behavior change is actually relevant and could be constrained to — when the upper layer has transparent pixels the user doesn’t know about and so doesn’t realize a mouse down will select the layer. In this rare situation it may make sense to click through the transparency. But if there’s no transparency, there’s no confusion about what’s being moused-down and so the mouse down failing to select is going to be a surprise.


Just hold Cmd / Ctrl when clicking

1 Like

This is just another case of agreeing to disagree. I’ve used XD and think their way is inferior, as there I can’t easily move layers that are underneath others.

The real solution here is for Figma to implement customizable keyboard shortcuts, which is long overdue already. In a perfect world, every application should go the Blender route and allow the user to customize the keybinds for literally any individual function or element on the interface.

That does not address the topic.

To clarify, do you frequently find yourself needing to drag layers that are both selected and that have area not obscured by other layers?

For my part I can’t remember the last time I needed to do that except for in outside of UI design in something like photoshop where I was dealing with lots of overlapping transparent layers.

The current solution makes both equally possible. If they change it, then manipulating visible layers will only be slightly less tedious, but manipulating hidden layers will be very tedious, so I think this is the best of both worlds.

Of course, if they change it, they can add some keybind for moving layers instead of selecting, but that would make the whole Figma community have to relearn what they’re already used to.

It’s hard to cater to everyone’s preferences. It’s like designing a tool for both left and right handed people. Like i said, I don’t think the real issue here is which one to use, but to give users the choice with customizability.

Appreciate the thinking but I’m afraid I’m not on board with any of it.

Just to clarify, my aversion isn’t the extra mouse action being more tedious it’s the frustration of a core idiom failing (the thing I move-gestured at was not moved, something else was). It’s table-flipping infuriating – like typing text and having to tap the ‘e’ key twice to make that character if it comes after ‘c’.

Ultimately I’m not convinced the ‘mouse down on a different element to drag a different selected element under it’ is a common action (or need). (Though i’m totally willing to be wrong about this!) So I don’t buy the cost to change argument. Moreover, the mouse down and drag gesture is not just frequent here, it’s frequent basically everywhere (up to and including how OS windows behave) and it’s a lot easier to relearn something used every now and then than it is to learn exceptions to a gesture otherwise used essentially everywhere.

Adjacent to the cost to change angle is the friction-while-learning which, given Figma is giving away the tool to students and educators, may be particularly salient.

I’m also not on board with the ‘let everyone customize everything’ as the panacea here. Can’t escape defaults (and students will learn and use them) so there’s still decisions to make.