-
Notifications
You must be signed in to change notification settings - Fork 47k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@halvves this looks great to me. Later today, I'll conduct some more general browser testing. I need to make sure these changes don't have an impact on the IE placeholder fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.