You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When an input is initially disabled, it is valid after enabling it, even when it shouldn't be.
For example, start with an <sl-input type="text" disabled required></sl-input>. Remove the disabled. Check the invalid property. It is false, even though the input is empty and required.
Thanks for reporting this, and for the repro. This is happening because checkValidity() reports true when an input is disabled. The solution is probably to watch disabled and set update input.invalid after the input is no longer disabled.
This probably affects most other form controls, too. It's a good first issue for anyone who wants to take a stab at it. (I'm trying to finish up the analyzer migration before moving onto anything else.)
I haven't gotten around to input tests yet, but this would be a great thing to test for once fixed.
This was fixed by updating the input's disabled state and rechecking validity. I'm setting it directly on the input instead of waiting for the next update to avoid having to wait two updates for the correct validity.
Update: I moved the logic into @watch decorators in a28942f.
Describe the bug
When an input is initially disabled, it is valid after enabling it, even when it shouldn't be.
For example, start with an
<sl-input type="text" disabled required></sl-input>
. Remove thedisabled
. Check theinvalid
property. It isfalse
, even though the input is empty and required.To Reproduce
Reproduced here in this lit playground.
Expected behavior
invalid
should be true in the case described above.I love your components! Thank you so much for your work ❤️
The text was updated successfully, but these errors were encountered: