prevent firefox marking required textareas invalid #16578
Conversation
Bug was caused by an IE10/IE11 bugfix dealing with the placeholder attribute and textContent. Solved by avoiding the IE bugfix when textContent was empty. Closes #16402
|
No significant bundle size changes to report. Generated by 🚫 dangerJS |
| ReactDOM.render(<textarea value="" readOnly={true} />, container); | ||
|
|
||
| expect(counter).toEqual(0); | ||
| }); |
There was a problem hiding this comment.
For others - we pulled this test from ReactDOMInput-test.js, which uses a similar technique to check mutations for an iOS Safari date bug.
I still think this is a weird test, and I wonder if it makes sense to create a common helper for this sort of thing.
| <b> | ||
| <i>not</i> | ||
| </b>{' '} | ||
| see a red aura, indicating the textarea is invalid. |
There was a problem hiding this comment.
Can you explain this a bit better? I do see a red outline specifically when I focus the "Empty value prop string" textarea, hit any character on the keyboard, and then move the focus to one of the other textareas. Is this expected?
There was a problem hiding this comment.
Interesting. Great catch! I don't think there is anything we can do about this though, assuming this is what's happening:
- A user enters text
- The onChange callback does not update state (no value change)
- The text is still entered, so React must assign an empty value to "control" it
- Firefox triggers validation on blur, and the input has been modified at this point, so the field is marked as invalid.
So controlling the input is at odds with input validation. I think this is okay for fields that don't allow any text input because they should really have readOnly on them instead of a blank change callback.
I think these are setup this way to avoid needing to scaffold out the controlled input code. Would it be less confusing if they were set up this way?
There was a problem hiding this comment.
Ah that seems reasonable. Maybe update the instructions then to be clearer about this case.
I think these are setup this way to avoid needing to scaffold out the controlled input code. Would it be less confusing if they were set up this way?
Not quite sure what you mean by that but I think what we have now is already better than what we had 🙂
There was a problem hiding this comment.
Oh! I just meant adding the callbacks and state for the controlled inputs so that the values are editable. Right now we don't have them, I think because it isn't essential for the fixture.
There was a problem hiding this comment.
updated expected result to read "...see a red aura on initial page load, indicating the textarea is invalid..."
do you think this is sufficient clarification?
re: @philipp-spiess code review
better describe the behavior we are testing for re: @philipp-spiess code review
There was a problem hiding this comment.
I've conducted browser testing cross IE, Firefox, Safari, and Chrome.
I think this is good to go, 👍. @philipp-spiess any final thoughts?
|
@halvves Thanks for being patient with us. This is good by me. Let's ship it. |
Bug was caused by an IE10/IE11 bugfix dealing with the placeholder attribute and textContent. Solved by avoiding the IE bugfix when textContent was empty.
Closes #16402
Test Plan
Open up DOM test fixtures and compare (in Firefox)...
local: http://screeching-degree.surge.sh/textareas
to latest: http://screeching-degree.surge.sh/textareas?version=16.9.0
...and verify that textareas are no longer marked invalid on load when required.
Also confirm that the original IE bugfix is still functioning as intended.