Summary
When a property exists on the old VNode but is omitted from the new VNode, the diff calls remove_property. The JavaScript implementation is delete self[prop], which does not reset native DOM properties implemented as prototype accessors.
For example, after rendering an element with disabled = true, rerendering it without that property can leave element.disabled === true.
This is different from #49: that issue covers an explicit true -> false update, while this issue covers Some(value) -> None / property omission.
Evidence
The removal path is here:
Several element helpers still put native values in the property map, including disabled, checked, value, multiple, hidden, required, controls, autoplay, loop, and muted.
There is already a comment acknowledging this behavior for the attribute-level disabled helper:
Minimal reproduction
A white-box runtime test using an element whose disabled property is an accessor on its prototype performs these two renders:
- Render with
disabled: true.
- Render the same node with the property omitted.
Observed result:
audit: removing a VDOM property resets the native property failed
assert_false(disabled): `true` is not false
Deleting the property does not invoke the native setter or restore its default.
Expected behavior
Removing a VDOM property should restore the corresponding DOM state, so a property does not remain stale after it disappears from the next VNode.
A generic delete is insufficient because reset values differ by property. Possible approaches include property-specific defaults, representing boolean state as attributes where appropriate, or retaining/restoring the element's initial/default value.
Suggested tests
Please cover at least:
Summary
When a property exists on the old VNode but is omitted from the new VNode, the diff calls
remove_property. The JavaScript implementation isdelete self[prop], which does not reset native DOM properties implemented as prototype accessors.For example, after rendering an element with
disabled = true, rerendering it without that property can leaveelement.disabled === true.This is different from #49: that issue covers an explicit
true -> falseupdate, while this issue coversSome(value) -> None/ property omission.Evidence
The removal path is here:
remove_propertyusesdelete self[prop]Several element helpers still put native values in the property map, including
disabled,checked,value,multiple,hidden,required,controls,autoplay,loop, andmuted.There is already a comment acknowledging this behavior for the attribute-level
disabledhelper:Attrs::disabledworkaround/commentMinimal reproduction
A white-box runtime test using an element whose
disabledproperty is an accessor on its prototype performs these two renders:disabled: true.Observed result:
Deleting the property does not invoke the native setter or restore its default.
Expected behavior
Removing a VDOM property should restore the corresponding DOM state, so a property does not remain stale after it disappears from the next VNode.
A generic
deleteis insufficient because reset values differ by property. Possible approaches include property-specific defaults, representing boolean state as attributes where appropriate, or retaining/restoring the element's initial/default value.Suggested tests
Please cover at least:
disabled: true -> omittedchecked: true -> omittedvalue: "x" -> omittedtrue -> falsebehavior from Vdom diff fail to detect disabled property change #49 remains intact