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 |
| ReactDOM.render(<textarea value="" readOnly={true} />, container); | ||
|
|
||
| expect(counter).toEqual(0); | ||
| }); |
nhunzaker
Aug 27, 2019
Collaborator
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.
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.
|
Awesome! I did see a red outline once (see inline comment), is that intended? |
| <b> | ||
| <i>not</i> | ||
| </b>{' '} | ||
| see a red aura, indicating the textarea is invalid. |
philipp-spiess
Aug 27, 2019
Member
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?
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?
nhunzaker
Aug 27, 2019
Collaborator
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?
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?
philipp-spiess
Aug 27, 2019
Member
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 🙂
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
nhunzaker
Aug 27, 2019
Collaborator
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.
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.
halvves
Sep 10, 2019
Author
Contributor
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?
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
|
I've conducted browser testing cross IE, Firefox, Safari, and Chrome. I think this is good to go, |
|
@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.