Readonly doesn't work on #States

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request → as a guide.

Did not test but still needs tests.

Added Reroll for 10.1.x as #26 patch failed to apply on 10.1.x.
Removed changes of "a/core/misc/states.es6.js" as file doesn't exist.

Thank you but please read the comments and tags before changing status. Still needs tests

fix command failures

Thank you for working on this but please see the tags also. This needs tests so this isn't ready for review.

Hey,

I have added state:readonly with running Javascript Tests as well.
I hope that is properly implemented for a valid core commit. :)

Test assertions added cover the change being made.

Ran locally without the fix and got failing assertions

Failed asserting that false is true.

Really wanted to commit that but readonly doesn't work on checkboxes, the test need to use an input type that supports the readonly attribute.

The attribute is added correctly and we can see that in the test, it's just that it's not supposed to do anything on radio/checkboxes/color/file/select

@nod_
Thank you for your feedback. I have done a little bit research on the spec and MDN.
Is far as I understand we have to limit the relvant input options to text, search, url, tel, email, password, date, month, week, time, datetime-local, and number or a negated version of checkbox, radio, file, range, color, hidden for the input types.

And for sure adjust the test suite properly. Am I right?

From MDN

The readonly attribute is supported by text, search, url, tel, email, password, date, month, week, time, datetime-local, and number types and the form control elements. If present on any of these input types and elements, the :read-only pseudo class will match. If the attribute is not included, the :read-write pseudo class will match.

The attribute is not supported or relevant to
or input types that are already not mutable, such as checkbox and radio or cannot, by definition, start with a value, such as the file input type. range and color, as both have default values. It is also not supported on hidden as it can not be expected that a user to fill out a form that is hidden. Nor is it supported on any of the button types, including image.

I don't think we need to be too precise, if someone uses it on an input that doesn't support readonly it won't break anything specifically.

great, thanks :)

@_nod

wow, you are great :) Thank you for the proactive obversation.
I just wanted to wait for the tests are green :D I think I got it. So thank you! :)

Just want one follow up question.
The visual representation of the state is nothing special by user agent style.
Should claro & olivero represent the readonly state equal to the disabled state on theme level?

We could open a new issue to address the styling of readonly fields. The styling is out of scope for this issue though.

The tests are right where they need to be, the additions are clean and follow the existing patterns in the test, are passing now (and as reported by smustgrave, failing when run without the fix).

The fix looks clean and good.

I don’t see any problems with the changes in the MR.

RTBC

thanks!
-Derek

Committed ac64dce and pushed to 10.1.x. Thanks!

Checked in with lauriii, If we consider this a bug (as in: it's expected to be available based on what is possible inside HTML forms), backporting to 10.0.x also because it's better to keep the states API in sync when possible.

Automatically closed - issue fixed for 2 weeks with no activity.