fix(vdom): don't update value property if it hasn't changed #602
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This addresses a problem we encountered with number inputs in Firefox, where
HtmlInputElement.value
will only return a valid number. or the empty string, instead of the actual contents of the input. This causes two problems in typical use, 1) it clears the input if the user enters an invalid character, and 2) it's not possible to enter the decimal point key-by-key since entering e.g.12.
will havevalue
return12
, thereby deleting the decimal point.The workaround implemented here is to simply not update the DOM if
value
seems unchanged. In the problematic case above it has, of course, and this will cause the input to become out of sync with the model. But the root of the problem is that it already is, and there seems to be no way to get the actual contents of the input. So it seems to me that the lesser evil is to accept that instead of forcing synchronization by clearing the input.Note that this is also what Elm does, and has done for years. It was implemented five years ago to address a different issue (that seems to be addressed with significantly more complex logic further down in this function, which we might now remove?). It therefore feels like a relatively safe change, or at least one that has been thoroughly tested in real world scenarios.
There is one known problem with this, however, also only in Firefox. If the input has invalid contents it's no longer possible to clear it by programmatically setting
value
to the empty string, since it will already appear empty and therefore not actually do anything. This is still unresolved in Elm.Another option to address this is to implement a more general opt-in mechanism for property-setting, but that seems like a much more invasive change. Although if we look to Elm again, it seems like most attributes are actually implemented using the equivalent property instead of the attribute.