Editor: Ensure there is no blinking Toolbar when inserting blocks between lines

[gziolo]

Description

When testing other PRs I noticed a very subtle bug where Block Toolbar blinks after you click on the in-between line inserter. This happens when you reach a very specific area close to the top and bottom edges. See screenshots.

This PR fixes this issue by preventing propagation of focus event to the BlockContextualToolbar. I'm not convinced this is the best solution in the long run, so happy to update if you have a better idea how to fix it.

How has this been tested?

Manually

Screenshots

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[aduth]

Related: #5658 (comment)

Specifically also the latter note here:

Edit: One of the first things I tried was to stop propagation of the focus event handled by the button, which is itself not ideal (stopping propagation never is), and resulted in another strange effect of the hover effects of the block never being dismissed.

This is also why the clickAtRightish function exists in the adding-blocks end-to-end` test, and should be removed if it can be fixed:

gutenberg/test/e2e/specs/adding-blocks.test.js

Lines 13 to 34 in 473ef22

	/**
	* Given a Puppeteer ElementHandle, clicks around the center-right point.
	*
	* TEMPORARY: This is a mild hack to work around a bug in the application
	* which prevents clicking at center of the inserter, due to conflicting
	* overlap of focused block contextual toolbar.
	*
	* @see Puppeteer.ElementHandle#click
	*
	* @link https://github.com/WordPress/gutenberg/pull/5658#issuecomment-376943568
	*
	* @param {Puppeteer.ElementHandle} elementHandle Element handle.
	*
	* @return {Promise} Promise resolving when element clicked.
	*/
	async function clickAtRightish( elementHandle ) {
	await elementHandle._scrollIntoViewIfNeeded();
	const box = await elementHandle._assertBoundingBox();
	const x = box.x + ( box.width * 0.75 );
	const y = box.y + ( box.height / 2 );
	return page.mouse.click( x, y );
	}

[gziolo]

@youknowriad, what was the reason why we moved BlockInsertionPoint inside BlocksListBlock component? It seems like this is the root cause why BlockToolbar gets focus in the first place.

[youknowriad]

@gziolo It was moved their to be shown properly for floated blocks (relative to the block's position)

[aduth]

I'm not inclined to add even more nested nodes to what already exists for a block, but one option is to apply the floating styles as a separate wrapper element which is not susceptible to the block's onFocus handling, where the block inserter would be a child to take advantage of the float, but not incur the block selection.

(There are some particular intricacies of this with wrapper tabIndex, getBlockFocusableWrapper)

[aduth]

There was also the idea of using the nested block's concept of layout for floated content. Last it was discussed, there was some various concerns expressed about how well it would cooperate with surrounding unfloated content, but off the top of my head it doesn't seem like any more of an issue than what exists today. The advantage here is that layout is one level above a block, which achieves a similar goal to the idea in #6276 (comment) (not having inserter be susceptible to block onFocus handling).

[gziolo]

It's no longer an issue. There was a change introduced which completely refines the way this inserter works. You can click only on the plus icon. Closing this PR.