Changing the value property of a textarea also implicitly changes (step 4) its selectionEnd and selectionStart properties. Since virtual-dom isn't aware of this, the in-memory copy of the dom now differs from the real dom in these properties, leading to bugs.
Adding the logic to handle this properly requires handling a lot of edge cases, so I couldn't find a nice way to implement it considering that these properties are uncommon and code size is important, hence this hotfix.
This hotfix always considers the selectionStart and selectionEnd properties modified, like we already do with value and checked. Setting these properties to themselves (moving the cursor/selection to where it already is) is idempotent so this should be safe.
I've tested this patch by modifying the js output by the compiler.
I've looked through the html spec; there doesn't seem to be other properties being implicitly modified.
Changing the
value
property of atextarea
also implicitly changes (step 4) itsselectionEnd
andselectionStart
properties. Since virtual-dom isn't aware of this, the in-memory copy of the dom now differs from the real dom in these properties, leading to bugs.Adding the logic to handle this properly requires handling a lot of edge cases, so I couldn't find a nice way to implement it considering that these properties are uncommon and code size is important, hence this hotfix.
This hotfix always considers the
selectionStart
andselectionEnd
properties modified, like we already do withvalue
andchecked
. Setting these properties to themselves (moving the cursor/selection to where it already is) is idempotent so this should be safe.I've tested this patch by modifying the js output by the compiler. I've looked through the html spec; there doesn't seem to be other properties being implicitly modified.