Block Editor: Only show block movers when block is selected.

[epiqueras]

Fixes #16681

Description

Avoids block movers overlapping when there are certain combinations of blocks, block selections, and/or hovers, by only showing them when a block is selected and not on hover.

How has this been tested?

Blocks were hovered and it was verified that the movers were not showing.

Screenshots

Types of Changes

Bug Fix: Only show block movers when block is selected.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[youknowriad]

I don't have a strong preference personally but I'd love thoughts from @mtias and @jasmussen as this is one of the early decisions and we should check the reasoning behind it as it does add an extra click if you'd want to move a block before selecting it.

[marekhrabe]

What if they showed on hover in case no block at all is selected? Would that be too magical?

[jasmussen]

Thanks for this PR, thanks for taking a stab at this.

It doesn't feel like it directly addresses #16681 though, not as I perceive it. @kjellr can you confirm?

What it does is always show it when the block is selected, and remove it entirely from hover. This has been suggested and discussed in the past, and while it's definitely an option on the table, it does not seem to add that much value, whereas removing the move-on-hover feature does retract a bit. It was intentially built so that these tools were immediately available.

However on a high level, this PR does simplify things a little bit. And one of the challenges that would be good to look at, is reducing the complexity of this mover control. In the not too distant future, we are likely to see blocks that require horizontal rearrangement of child block. Think: a navigation menu where you can sort the items horizontally. It would be nice to do some "back to basics" thinking on how blocks are moved — potentially an idea is out there that allows us to both simplify this mover, and make it work in multiple directions.

[kjellr]

It doesn't feel like it directly addresses #16681 though, not as I perceive it. @kjellr can you confirm?

I think this technically solves the problem. But it goes about it in a different way than I'd been thinking. I'd thought we should keep the current ability to show movers on non-selected blocks, but just make sure that only one instance of block movers is visible at any given time. So when a new set of block movers becomes visible, all other instances of block movers disappear.

This does make things simpler, but I do agree that it requires extra clicking to move things around. I'd probably vote to hold off for a different solution.

[epiqueras]

What if we only show block movers when hovered, and not when just selected?

Otherwise we would need to hoist hover state up into a parent or into the store so that selected blocks can hide their block movers when they see that another block is hovered. Unless I missed a simpler way to do it. cc @youknowriad

[jasmussen]

What if we only show block movers when hovered, and not when just selected?

Can you elaborate?

One of the things that happens when you click on the mover, or drag, is that the block gets selected also. So if the movers are only available on hover, it would effectively break things, if I'm understanding things correctly. Additionally we need them to be keyboard accessible.

[epiqueras]

One of the things that happens when you click on the mover, or drag, is that the block gets selected also. So if the movers are only available on hover, it would effectively break things, if I'm understanding things correctly. Additionally we need them to be keyboard accessible.

You can still hover over a selected block. Basically, only show the movers when the mouse is on top of the block, regardless of whether it's selected or not.

[mapk]

Looks like this has been resolved with this duplicate: #17315

For this reason, I'm closing this PR.