Input Interaction: restore collapsing selection before edge calc

[ellatrix]

Description

Fixes #14871.
Regression caused by #14871.

Specifically, the following code should not have been removed:

gutenberg/packages/dom/src/dom.js

Lines 89 to 95 in 0563f6f

	// Create copy of range for setting selection to find effective offset.
	const range = selection.getRangeAt( 0 ).cloneRange();
	// Collapse in direction of selection.
	if ( ! selection.isCollapsed ) {
	range.collapse( ! isSelectionForward( selection ) );
	}

How has this been tested?

Screenshots

Types of changes

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.

[ellatrix]

Hm, I ran the e2e test against master, but it does not fail. Looking again.

[ellatrix]

Fixed. Looks like it needed minimum three characters per line.

[ellatrix]

I'm not sure why this code change makes 6fa60b2 needed, but this seems the correct behaviour to me now.

[ellatrix]

The fixed test was introduced in caaf204, which also introduced the code that was removed. But again, the fixed test in this PR seems like the correct behaviour to me. Twice arrow up from a certain horizontal position should land the caret in the same horizontal position if possible.

[ellatrix]

I think the reason is that the range is now cloned, before handing it to getRectangleFromRange.

getRectangleFromRange may unexpectedly modify the live range:

gutenberg/packages/dom/src/dom.js

Lines 205 to 215 in 0bc9067

	// If the collapsed range starts (and therefore ends) at an element node,
	// `getClientRects` can be empty in some browsers. This can be resolved
	// by adding a temporary text node with zero-width space to the range.
	//
	// See: https://stackoverflow.com/a/6847328/995445
	if ( ! rect ) {
	const padNode = document.createTextNode( '\u200b' );
	range.insertNode( padNode );
	rect = range.getClientRects()[ 0 ];
	padNode.parentNode.removeChild( padNode );
	}

[aduth]

Twice arrow up from a certain horizontal position should land the caret in the same horizontal position if possible.

Yes, I compared the results of the test steps on master and this branch before seeing your comment, and it very much seems like the correct / improved behavior (you can see in the comment box here on GitHub that a native textarea behaves the same).

[aduth]

Makes sense, tests well.

Not so sure about where cloneRange in getRectangleFromRange is necessary, but I don't think it can hurt anyways. I'll leave it to your discretion on my feedback.

[aduth]

It reminds me of some unrelated testing I'd been doing with Chrome line-ending bugginess, where Range#cloneRange wasn't actually avoiding mutations to the original:

https://codepen.io/aduth/pen/WPjQoW

(See comment: "// WIP: Buggy, collapses spaces (mutates original).")

I never did figure out what I was seeing with my demos. I raise only in case there's still a worry about mutating the cloned value.

[ellatrix]

I've not tested the Codepen, but when you make this change in master, this test will also fail:

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

Lines 64 to 71 in 917338c

	// Verify vertical traversal at offset. This has been buggy in the past
	// where verticality on a blank newline would skip into previous block.
	await page.keyboard.type( 'Foo' );
	await page.keyboard.press( 'ArrowUp' );
	await page.keyboard.press( 'ArrowUp' );
	await pressKeyTimes( 'ArrowRight', 3 );
	await pressKeyTimes( 'Delete', 6 );
	await page.keyboard.type( ' text' );

It is true that cloning the range in isEdge will also prevent this issue, but I think it is safe to clone here is well in case it is called with a live range.

In my testing insertNode doesn't modify the original range.

[aduth]

I'd kinda wonder why it matters, i.e. while true that we're mutating the range, we're also following up with a mutation to remove the added node, which means it should be effectively the same. I'm not entirely clear from the conversation of the pull request what impact this change is having.

[ellatrix]

We do update the DOM again, but not through the range API which may explain why its not restored.