Controlled <input type="email" /> doesn't behave like other controlled inputs

[danott]

Do you want to request a feature or report a bug?

🐛

What is the current behavior?

Leading and trailing whitespace can remain present on a controlled <input type="email" />, even when the controlling value has the whitespace removed.

What is the expected behavior?

Leading and trailing whitespace should not remain present on a controlled <input type="email" />, even when the controlling value has the whitespace removed.

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

I discovered this while using React 16.8.2 in Safari Version 12.0.2 (14606.3.4)

Here's a code sandbox that demonstrates the behavior: https://codesandbox.io/s/1ozyz1kn5l

[jeroenvisser101]

@danott browser implementations of type="email" inputs might vary, but internally, the value is already trimmed/stripped of spaces, and because the browser regards "".trim() === " ".trim(), the onChange event is never fired.

https://stackoverflow.com/questions/41955069/value-of-input-with-type-email-doesnt-contain-spaces

[danott]

@jeroenvisser101 I'm not understanding how comparing strings after trim()should change the expected behavior of a controlled input? Is trim used somewhere in the internals? Speaking from the position of a user of React's top level API, if an input is controlled with the value prop, I expect that value to be directly reflected regardless of browser implementation?

I've amended the Code Sandbox above to include buttons that are outside the inputs' onChange handlers. What's interesting about this addition, is that the <input type="email" /> strips the leading/trailing whitespace from the controlled value (surprising!), while the <input type="text" /> retains it (expected). While having whitespace inside an <input type="email" /> is probably never valid... the biggest thing I'm trying to highlight is using <input type="email" /> as a controlled input has some surprising behavior, where the controlling value doesn't seem like it's truly in control?

[nhunzaker]

@danott ideally, the browser implementation details would not change the behavior of controlled inputs. This is just a particularly painful bug because the tools we have in the browser to deal with it are limited.

For another example, assigning leading/trailing spaces on email inputs has challenges too. The input strips the whitespace on assignment:

https://codepen.io/nhunzaker/pen/vbojvb

Eliminating spaces on value assignment and value retrieval has been a really difficult issue to overcome.

Having said that, I don't want to discount your frustration. I really want to iron this out too. Edit: particularly cases that cause strange user experience during text entry, even if we can't fully control all cases for the email input.

[danott]

Having said that, I don't want to discount your frustration.

No worries! I was coming more from a place of surprise rather than frustration. For my use case, the HTML5 semantics weren’t critical, so I transitioned from type=“email” to type=“text”, and we’re good to go in production. 🙂

Eliminating spaces on value assignment and value retrieval has been a really difficult issue to overcome.

As I dig into the edges of this behavior, that is ringing very true. Thanks for taking the time to help me understand, and providing additional examples.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

[stale]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!