Repository navigation
Lost nuance of hit detection between blocks #28682
Description
Description
Clicking the area between blocks now always selects the next block whereas before it would select the block closest to the clicked point. Also, the placement of the editing caret appears at the end of the block content whereas before it was placed as close to the clicked point as possible.
UPDATE: Revised title/description and added new screen captures (and removed one old one) in order to more clearly indicate what has changed.
Step-by-step reproduction instructions
- In a block editor running the latest Gutenberg from master try clicking just below the visible content of a block and observe which adjacent block is selected.
- Try the same on the version of Gutenberg built into WP 5.6 and observe the difference.
Expected behaviour
On a click between blocks, the block closest to the click is selected
Actual behaviour
On a click between blocks, the next block is selected.
Screenshots or screen recording (optional)
| WP 5.6 | Gutenberg plugin since at least e4eb4be |
|---|---|
 |
 |
Gutenberg plugin built from e4eb4be
This video shows that the regression can be particularly frustrating in the case of very short blocks like the Seperator. A click on the line itself appears not to work* and that the click has to be above the line in order to select the Separator.
*The appearance that a click on the line does not work is likely due to the location of the hotspot in the macOS cursor.
block-selection-master-e4eb4be3a9.mp4
WordPress information
- WordPress version: 5.6.0
- Gutenberg version: 9.8.0 (I think, it's present since at least e4eb4be)
- Are all plugins except Gutenberg deactivated? Yes
- Are you using a default theme (e.g. Twenty Twenty-One)? Yes
Device information
- Device: Desktop
- Operating system: macOS 10.12.6
- Browser: Chrome 88.0
Activity
[-]Block hit area regression[/-][+]Lost nuance of hit detection between blocks and ensuing caret placement [/+]stokesman commentedon Feb 8, 2021
I dug in a bit and figured this code removed in #27860 looked like the cause. To confirm, I tried a revert of 30fafd0 and dd80022 which did produce a build that resolves this.
youknowriad commentedon Feb 9, 2021
I'm not sure we should focus the closest point personally. I chose to focus the next block but I think we can choose to focus the "start" of the next block or the "end" of the previous block. I don't think there's a big value in trying to find the horizontal position.
stokesman commentedon Feb 9, 2021
That would address the main concern I mean to raise here that the previous block is never selected.
I'd brought up the caret placement as something that changed, but indeed, it doesn't seem important given that if you intend to set the caret somewhere, it's probably not too hard to hit that spot.
[-]Lost nuance of hit detection between blocks and ensuing caret placement [/-][+]Lost nuance of hit detection between blocks[/+]pshryock-nba commentedon Jun 17, 2026
Is there any update on fixing this issue?