Bug: Constraint Validation API not reflected on Textarea's value attribute change

[tdiluzio]

Hi,

thank you very much for what you do and you've been doing so far.

I've been working on some form validations via the Validation Constraints API and I've noticed that event.target.validity read-only object doesn't get updated and is always valid although some constraints are set when the value attribute is set to the Textarea.

On the other hand, when value is passed as children validity gets updated as expected but I'm being warned to Warning: Use the defaultValue or value props instead of setting children on <textarea>

React version: 16.13.1

Steps To Reproduce

Here's how you can reproduce:

1. setup this basic app component with one Textarea element, set some constraints and add the value attribute as you normally would on any form.

2. add another Textarea element but instead of passing value as an attribute pass it as children see code below

import React, { useState } from 'react';

function App() {
  const [state, setState] = useState({
    first: '',
    second: '',
  });

  function handleTextChange({ target }) {
    const { name, value, validity } = target;

    setState({
      [name]: value,
    });

    console.log(`${name} validity:`, validity);
  }
  return (
    <div className="App">
      <textarea
        name="first"
        placeholder="First"
        value={state.first}
        onChange={handleTextChange}
        required={true}
        minLength={10}
      />

      <textarea
        name="second"
        placeholder="Second"
        onChange={handleTextChange}
        required={true}
        minLength={10}
      >
        {state.second}
      </textarea>
    </div>
  );
}

export default App;

2. Open your console

3. Type at least one character into the first Textarea see screenshot

4. Type at least one character into the second Textarea see screenshot

The current behavior

You'll notice that the first Textarea ignores the validation constraints set

The expected behavior

Validation constraints should be set and field should be invalid

Link to code example

Please find sample code at https://github.com/tdiluzio/react-dom-textarea-bug

Demo

Here's the URL to the demo https://tdiluzio.github.io/react-dom-textarea-bug/

[stale[bot]]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[richyst]

I'm having exactly the same issue in version 18.2.0 https://stackoverflow.com/questions/74738542/inconsistency-with-validitystate-api-between-chrome-and-firefox

[devongovett]

I investigated this issue and I believe it is caused by these lines: https://github.com/facebook/react/blob/77c4ac2ce88736bbdfe0b29008b5df931c2beb1e/packages/react-dom-bindings/src/client/ReactDOMTextarea.js#L76-L82

Updating the element's defaultValue property is equivalent to changing the children of the textarea element. When the children change, Chrome marks the change as a programmatic update rather than a user update here. Then, when checking validity, it skips the length constraint for programmatically set changes here.

This is another problem caused by syncing the value prop with the DOM, in a similar vein to the problems described in #11896. A workaround it to set defaultValue="" in addition to value, which skips the above if statement, but then React emits a warning about having both controlled and uncontrolled props.

Since minLength and maxLength basically don't work at all for controlled textareas at the moment, I think changing React's behavior to not sync value into the DOM only when those props are set would probably not be a breaking change? I might try opening a PR for that and see what others think.

[github-actions[bot]]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[jrenjilian]

I ran into this this week in React, and opened a Chrome bug with a pure JS reproduction before finding this issue: https://issues.chromium.org/issues/333940413

[github-actions[bot]]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[github-actions[bot]]

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!