fix(runtime): correct boolean attribute handling for form-associated components #6280
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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
3 tasks
3 tasks
|
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. |
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
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