fix(runtime): correct boolean attribute handling for form-associated components#6280
fix(runtime): correct boolean attribute handling for form-associated components#6280christian-bromann merged 2 commits intomainfrom
Conversation
…components For form-associated components, boolean attributes like `disabled` should follow HTML spec behavior where the presence of the attribute (regardless of its value, including "false") makes the property `true`. - Modified parsePropertyValue() to accept optional isFormAssociated parameter - For form-associated components: any string attribute value becomes `true` - Preserved legacy behavior for non-form-associated components - Updated all parsePropertyValue() call sites to pass form-associated flag Fixes #5461
|
I've published a dev release |
|
Hi there, I just wanted to point out that this change does appear to have introduced breaking changes, at least in some cases we've encountered. While I understand it's a bug fix and that aligning behavior for form-associated custom elements is the right direction, it may still have unexpected side effects for existing implementations. That said, I agree with the direction, and really appreciate the time and effort you all put into this work. |
I agree that this is a welcome fix, but it has led to a breaking change in our design system. |
What is the current behavior?
GitHub Issue Number: #5461
Currently, form-associated Stencil components incorrectly handle boolean attributes like
disabled. Whendisabled="false"is set on a form-associated component, Stencil parses the string"false"as booleanfalse, which then gets reflected back to the DOM as thedisabledattribute. According to HTML specification, for form-associated elements, the mere presence of boolean attributes likedisabled(regardless of their value) should disable the element.This causes form-associated components to behave incorrectly when
disabled="false"is explicitly set, as the component remains disabled when it should be enabled.What is the new behavior?
For form-associated components, boolean attribute parsing now follows HTML specification:
"false") is parsed as booleantrue""is parsed as booleantruefalse) continue to work as expectedFor non-form-associated components, the legacy behavior is preserved:
"false"continues to be parsed as booleanfalsetrueThis ensures form-associated components behave correctly according to HTML standards while maintaining backward compatibility for existing non-form-associated components.
Documentation
No documentation changes required - this is a bug fix that aligns existing behavior with HTML standards.
Does this introduce a breaking change?
This is a bug fix that corrects incorrect behavior. Non-form-associated components maintain their existing behavior, ensuring backward compatibility.
Testing
parsePropertyValue()function to accept an optionalisFormAssociatedparametersrc/runtime/set-value.tssrc/runtime/proxy-component.tssrc/runtime/client-hydrate.tssrc/hydrate/platform/proxy-host-element.tsdisabled="false"by not setting the disabled attribute when the property value isfalseOther information
This fix specifically addresses the issue where form-associated custom elements with
disabled="false"would incorrectly remain disabled due to improper boolean attribute parsing. The solution follows HTML specifications while preserving existing behavior for non-form-associated components.Key technical changes:
parsePropertyValue()with form-associated component detection