-
Notifications
You must be signed in to change notification settings - Fork 46.2k
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
Don't detach value from defaultValue for submit/reset inputs #7197
Conversation
👍 |
I'm curious, could it be enough to just do it when Also, what about |
Side question, if the idea is to "Detach value from defaultValue", couldn't you achieve the same by setting |
That was my initial thought too but I wasn't sure so I went with the minimal change. You're right that there are others. I think I've honestly lost track of the complicated logic going on around inputs. Maybe we can use defaultValue… Not sure what the implications are around controlled vs uncontrolled inputs. Since @jimfb just did a bunch of this input including these lines of code, hopefully he has better insight. |
If we use something like defaultValue, I would be a little worried about how controlled components behave with regards to reset buttons and placeholder text (especially on old browsers like IE8/9), so we would need to test those at the very least. The change @zpao added feels safest to me. |
With regards to checking for empty string... again, feels like we're going to hit edge cases. In particular, I'd worry about that attribute existing on all inputs (like reset buttons) and worried about failing to properly detach when the value was the empty string. |
No, it only works if you set |
IE 8 & 9 didn't support the FWIW I think reading Is there anything more specific we'd want to look out for (eg a flow that you expect might break). I'm having some trouble figuring out what the intent behind detaching from defaultValue is. I thought I figured it out for a second but then lost it. Surely something related to controlled components couldn't construct a case. |
Sounds optimistic to me...
|
You can read it and it is empty, that's why this PR exists in the first place. However if we were checking for In other words, replace the same code I replaced here but with this: var value = node.value;
if (value !== '') {
node.value = value;
} |
But then you aren't detaching if the initial value is the empty string. |
Chromium source makes it sound like button, reset, image, submit, hidden, checkbox, radio is the complete list of types where value and defaultValue are stored separately. (Mostly got that from https://cs.chromium.org/search/?q=storesValueSeparateFromAttribute&sq=package:chromium&type=cs, then grep BaseButtonInputType and BaseCheckableInputType.) In addition, file throws when you set its value to anything other than an empty string – though that shouldn't cause this in particular to be a problem because this happens on initial render. But it sounds like reset and submit are the only ones where they have another default value set: So this change is probably fine. |
I agree, this change seems perfectly fine to me. The proposed potential alternatives seem to introduce additional risk without introducing additional value, as far as I can tell. |
I'm curious, could this be an issue if you move away from a page and then back? In some cases the browser will restore what was previously written in the fields AFAIK (might require SSR), that might be an issue in this case with |
(cherry picked from commit 5c737b9)
Fixes #7179
This intentionally ignores both submit and reset inputs from the value detaching code. I'm mostly certain that the only result of the code there for these input types was to set the value to an empty string (if no value was provided). This is because that's what the value was, however browsers do show a default text for value-less inputs of those types (since they are actions). These default values aren't actually accessible the DOM afaict so we don't have a good indication apart from looking at the value in props. But since it doesn't appear to matter, I just skip this step entirely.
Test Plan: jsfiddle in #7179 no longer shows empty submit input.
cc @jimfb, @spicyj