Problem/Motivation

When I use the #state structure below to turn a text field into read-only depending to a checkbox selection, simply nothing happens.

    'states' => array(
      'readonly' => array(
        ':input[name="text_field"]' => array('checked' => TRUE),
      ),
    ),

If I use 'disabled' instead of 'readonly' the code works perfectly! But I really need the "readonly" option because I want to save the value filled in the text field before. The "disabled" option doesn't allow to save the field value.

Proposed resolution

I found a simply solution that solves the problem with few lines: just implement the "readonly" option in the file states.js, the same way it is done with the "disabled" option. This way, readyonly works very well.

Issue fork drupal-2866383

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

luizps created an issue. See original summary.

luizps’s picture

Following the W3C specifications for ready-only (https://www.w3.org/TR/html4/interact/forms.html#h-17.12.2), the solution applies the "readonly" option only to input and textarea fields.

luizps’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 2: drupal_core-2866383-readonly-doesnt-work-on-states-2.patch, failed testing.

luizps’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 2: drupal_core-2866383-readonly-doesnt-work-on-states-2.patch, failed testing.

luizps’s picture

Status: Needs work » Needs review
intrafusion’s picture

I confirm the patch in #2 solves this problem

dev.patrick’s picture

Status: Needs review » Reviewed & tested by the community
caminadaf’s picture

+1 RTBC

dieterholvoet’s picture

I updated the patch for the 8.7.x branch.

Status: Reviewed & tested by the community » Needs work
savel’s picture

Status: Needs work » Needs review
StatusFileSize
new648 bytes

DieterHolvoet, sorry to tell, but you might better don't do it this way.
The issue is for D7 and it was RTBC.
Automated testing system tried to apply your D8 patch to D7 and it failed.

I just put #2 back and it possibly needs to be reviewed again by community to put it to RTBC and wait for commit.

savel’s picture

Sorry, my windows machine has added .txt extension to the patch and I've missed it.

Again, it's just a reroll of #2 wich was RTBC before.
Please, review it and set to RTBC state again.

savel’s picture

Sorry, it happened again.

The patch from #2 as is. It was RTBC before patch for 8.x was added to the thread.

nikolas.tatianenko’s picture

Status: Needs review » Reviewed & tested by the community
Oscaner’s picture

Version: 7.x-dev » 8.7.x-dev
StatusFileSize
new555 bytes

For core 8.7.x

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs tests

This needs to change states.es6.js and compile it to make states.js - see https://www.drupal.org/docs/8/frontend-developer-tools-for-drupal-core

Also thanks for filing this bug report and for fixing it. Bug fixing is very valuable. However in order to commit a bug fix we need an automated to test to prove that we've fixed the bug and ensure that we don't break it again in the future. For more information about writing tests in Drupal 8 see the following links:

  1. https://www.drupal.org/docs/8/testing
  2. https://api.drupal.org/api/drupal/core%21core.api.php/group/testing/8.7.x
klonos’s picture

Been trying to test this (in D7 and Backdrop), but readonly does not seem to have any effect on the browsers. I then did some research and noticed this: https://html.spec.whatwg.org/multipage/input.html#attr-input-readonly

Only text controls can be made read-only, since for other controls (such as checkboxes and buttons) there is no useful distinction between being read-only and being disabled, so the readonly attribute does not apply.

Version: 8.7.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Branches prior to 8.8.x are not supported, and Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

rp7’s picture

Re-rolled patch in #17 for 9.1.x.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

nikhil_110’s picture

narendra.rajwar27’s picture

Status: Needs work » Needs review
StatusFileSize
new1.34 KB
new1.29 KB

Fixing custom commands failure.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs Review Queue Initiative

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.

Abhisheksingh27’s picture

Status: Needs work » Needs review
StatusFileSize
new614 bytes

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.

smustgrave’s picture

Status: Needs review » Needs work

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

nitin shrivastava’s picture

StatusFileSize
new664 bytes
new664 bytes

fix command failures

nitin shrivastava’s picture

Status: Needs work » Needs review
smustgrave’s picture

Status: Needs review » Needs work

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

sunlix made their first commit to this issue’s fork.

sunlix’s picture

Version: 9.5.x-dev » 10.1.x-dev
Status: Needs work » Needs review

Hey,

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

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs tests

Test assertions added cover the change being made.

Ran locally without the fix and got failing assertions

Failed asserting that false is true.

nod_’s picture

Status: Reviewed & tested by the community » Needs work

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

sunlix’s picture

@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.

nod_’s picture

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.

nod_’s picture

Status: Needs work » Needs review

great, thanks :)

sunlix’s picture

@_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 have 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?

nod_’s picture

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

nod_’s picture

Assigned: luizps » Unassigned
dww’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +Bug Smash Initiative

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

  • nod_ committed ac64dce7 on 10.1.x
    Issue #2866383 by sunlix, SAVEL, Nitin shrivastava, narendra.rajwar27,...
nod_’s picture

Status: Reviewed & tested by the community » Fixed

Committed ac64dce and pushed to 10.1.x. Thanks!

  • nod_ committed 8dcb9036 on 10.0.x
    Issue #2866383 by sunlix, SAVEL, Nitin shrivastava, narendra.rajwar27,...
nod_’s picture

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.

luenemann’s picture

Version: 10.1.x-dev » 10.0.x-dev

Status: Fixed » Closed (fixed)

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