Prevent a block and console error for input[type=email]

[kienstra]

Description

Fixes an issue where if an input[type="email"] is at the top of a block, there's a block and console error. Though this is fixed once you reload the page.

How has this been tested?

Steps to reproduce:

1. Use Chrome or Firefox, any WordPress version, like 5.5.1, and the master branch of Gutenberg
2. Create a new post
3. Copy this into the console:

wp.blocks.registerBlockType(
	'example/email-input-reproduce-issue',
	{
		title: 'Email Input',
		category: 'common',
		icon: 'wordpress-alt',
		keywords: [ 'Foo' ],
		attributes: {
			'email': {
				type: 'string',
			},
		},
		edit: function( props ) {
			return wp.element.createElement( 'input', { type: 'email', value: props.email } );
		},
	}
);

4. Insert the 'Email Input' block you just registered:
5. Expected: The block should display
6. Actual: There's a block and console error:

DOMException: Failed to set the 'selectionStart' property on 'HTMLInputElement': The input element's type ('email') does not support selection.
    at placeCaretAtHorizontalEdge (https://path/to/wp-content/plugins/gutenberg/build/dom/index.js?ver=cbf62a0bae5cfd2eeff038ee115edc0a:390:32)

That error is from:

gutenberg/packages/dom/src/dom.js

Line 281 in efc836a

container.selectionStart = 0;

It looks like the selectionStart property applies 'only to text/number-containing or elements'.

Screenshots

With this PR, there's no error:

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.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.

[kienstra]

Hm, the PHPUnit failure above is from:

/var/www/html/wp-content/plugins/gutenberg/phpunit/class-block-supported-styles-test.php

...which this PR doesn't touch.

That's failing on the master branch also.

[kienstra]

This should be ready for review, not planning any more commits unless more builds fail.

[nickcernis]

Looks good! I confirmed the original report and fix.

Before:

After:

[kienstra]

Hi @ellatrix,
Would you be able to review this when you have a chance? Thanks!

[talldan]

This looks like a worthwhile fix given an email input currently crashes the block 😓 .

The issue that I noticed when testing is that up/down arrow key navigation doesn't work in the same way for email inputs as it does for other inputs (see the search block for an example), the input is essentially a trap for navigating between blocks unless the user switches to navigation mode using escape.

I'm not sure if that's related to the change here or if some other code needs to be fixed. @ellatrix any thoughts?

[ellatrix]

It sounds like we need to adjust isEdge too?

[diegohaz]

Thanks a lot for contributing @kienstra! I just created #28559 based on this PR. I believe that solves this issue without the side effects @talldan mentioned.

[t-hamano]

Having checked this PR again, I assume that a similar problem may have been solved by #40192.

The issue that I noticed when testing is that up/down arrow key navigation doesn't work in the same way for email inputs as it does for other inputs

This issue also appears to have already been resolved.

@talldan @ellatrix
I think we can close the following issues and PRs, how do you think?

• Prevent a block and console error for input[type=email] #26074
• Fix error when block is an email input #28559
• DOMException: Failed to set the 'selectionStart' property on 'HTMLInputElement' #26983

Screencast

a5ae0e684f5beec00021d34de13f172b.mp4