RichText/Input Interaction: use ZWNBSP as padding

[ellatrix]

Description

<br> elements as padding for rich text elements proved to be no good.

• List padding is broken in Firefox. See RichText: stabilize onSplit #14765 (comment).

• Using line breaks as padding can cause some subtle range-to-rectangle bugs. See Input Interaction: take into account container padding #14804 (comment). The following code tries to account for that, but doesn't fully succeed in some cases.

gutenberg/packages/dom/src/dom.js

Lines 176 to 218 in 6cb0b32

	/**
	* Get the rectangle of a given Range.
	*
	* @param {Range} range The range.
	*
	* @return {DOMRect} The rectangle.
	*/
	export function getRectangleFromRange( range ) {
	// For uncollapsed ranges, get the rectangle that bounds the contents of the
	// range; this a rectangle enclosing the union of the bounding rectangles
	// for all the elements in the range.
	if ( ! range.collapsed ) {
	return range.getBoundingClientRect();
	}
	const { startContainer } = range;
	// Correct invalid "BR" ranges. The cannot contain any children.
	if ( startContainer.nodeName === 'BR' ) {
	const { parentNode } = startContainer;
	const index = Array.from( parentNode.childNodes ).indexOf( startContainer );
	range = document.createRange();
	range.setStart( parentNode, index );
	range.setEnd( parentNode, index );
	}
	let rect = range.getClientRects()[ 0 ];
	// 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 );
	}
	return rect;
	}

If we use zero width spaces as padding, the calculation is more reliable, and Firefox doesn't have any issues.

It also fixes an issue in the list block, where to browser moves the selection from an empty text element between a br and nested list to the start of the nested list.

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.

[aduth]

The build failure appears to be legitimate. I can also reproduce locally that when pressing ArrowDown from a bottom-padded paragraph, the caret is not placed in the text field (though the <p contenteditable> does become the active element).

[ellatrix]

@aduth Yeah, I know, I haven't had the chance to look at it yet.

[ellatrix]

I can't reproduce the error locally. :/

[aduth]

Testing again, I still observe issues, though in my case it works for the ArrowDown from the padded field, but the caret becomes lost when pressing ArrowUp to try to get back to the first field.

I created a screen recording in case it helps provide any useful context: https://cloudup.com/crRofrsTvMJ

[aduth]

In debugging, I notice that in placeCaretAtVerticalEdge, it computes a new range using hiddenCaretRangeFromPoint, where the range object produced by this function is anchored to a button in the block contextual toolbar:

Unclear if this might explain the issue (it's trying to move the selection into the hidden toolbar button?). I'm assuming the caretRangeFromPoint might be misidentifying some hidden elements.

If you're having trouble reproducing, it may be that you're configured to use the Fixed toolbar?

[ellatrix]

@aduth I don't see a toolbar in the video you shared. Not sure how it would catch the selection...

[ellatrix]

I have no idea what this code is for. Apparently I wrote it! :) Since we're moving from a br element to a text element for an empty rich text, this calculation makes should navigate contenteditable with padding fail.

Since I don't understand what this is for, and there are no failing e2e tests when removing the code, I think it's safe to remove. If we end up needing it again, we should comment it better and add e2e tests.

[ellatrix]

@aduth This appeared to be the culprit of the e2e test failure.

[aduth]

It could help to have some documentation about what these special characters are intended to be used for.

[ellatrix]

Thanks @aduth!

[dmsnell]

@ellatrix thanks for making this change that improved things with the editor and list and all that. I'm coming late to the part but have a question about the character being used. It seems that the use of U+FEFF for zero-width space or zero-width joining was deprecated in 2002 in TR28, being replaced by the favored ZWJ. This was because the code point was in use both for the byte-order-mark (BOM) and also the joiner.

Was U+200B (zero-width space) or even U+200C (zero-width non-joiner) considered for this role? Or any other characters? I think it could be worth replacing this character with another that doesn't involve the confusion.

[ellatrix]

@dmsnell

The problem with the zero-width space is that it could have some usage in text. The zero-width non-joiner also seems to be used for typography.

The zero-width non breaking space is taken over from TinyMCE. The fact that it's deprecated is actually a good thing. That means it will doesn't have any real usage in text anymore, so it's won't clash with anything.

I'm always open to alternatives. Maybe we can use one of the control characters. But if there's no real problem with using it, I'm not sure if we could replace it.

[dmsnell]

The fact that it's deprecated is actually a good thing. That means it will doesn't have any real usage in text anymore, so it's won't clash with anything.

The character isn't deprecated, just its use as we are using it, or as TinyMCE did. It's still used as a byte-order mark in other places.

Maybe we can use one of the control characters

Did we consider some private-use characters or field separators? I'm guessing this is used to delineate formatted regions? Does the character have to have a visual representation that's invisible and zero-width?

We have U+1D, for example, the "group separator" and it seems to display invisibly (without a replacement character). Some of these old control codes I've never seen in practice despite having fairly semantically-related meanings.

[ellatrix]

The character isn't deprecated, just its use as we are using it, or as TinyMCE did. It's still used as a byte-order mark in other places.

Ok, the use as a space character is deprecated, which makes it pretty much useless in text for users. If it was still used as a space character, then we wouldn't be using it.

Did we consider some private-use characters or field separators?

That's what I mean with control characters. I'm just wondering why ZWNBSP is problematic.

Does the character have to have a visual representation that's invisible and zero-width?

Yes, it has to be zero width. U+1D seems to be fine for that.

[dmsnell]

I'm just wondering why ZWNBSP is problematic.

It stood out to me when I was debugging the other issue where they were bleeding out of RichText. I'm not entirely sure of this, but I think the main problem (besides the fact that ZWNBSP as a character "doesn't exist" anymore - it does of course, but shouldn't be used) is that we don't expect to find the BOM in the middle of a text stream (it should come as the first unit in the stream).

To my knowledge nothing is broken because of the use of this character; it's more that I came across it and was confused at its use, and it distracted me while trying to fix the matter at hand. My question was focused on (a) did we have an intentional reason to pick the BOM or did we choose it because it was invisible and rare, and (b) if the first part is "no" then I wonder if there aren't characters more closely designated for the purposes we're using them for.