Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
In the "disabled" state change handler, a "form-element" class is needlessly filtered out from the result set (which contains only one target element anyway). This is useless, since the class "form-element" doesn't exist, so I presume this is a leftover from some pre-initial commit testing.
File: misc/states.js
Steps to reproduce: always.
Patch in comment #1.
Comment | File | Size | Author |
---|---|---|---|
#12 | 1263302-states-disabled-12.patch | 685 bytes | andypost |
#6 | 1263302-states-disabled-5.patch | 705 bytes | andypost |
#4 | 1263302-states-disabled-d78-4.patch | 685 bytes | andypost |
#1 | states-remove-form-element-filter-1263302-1.patch | 466 bytes | peterpoe |
Comments
Comment #1
peterpoe CreditAttribution: peterpoe commentedPatch.
Comment #2
rommelxcastro CreditAttribution: rommelxcastro commentedhi, is this open or closed?
Comment #3
andypostThis patch solves only a patch of trouble, the disabled element is DIV but disabled attribute affects only inputs
Comment #4
andypostPatch includes #1 and also extends disbled attribute to all (select, input, textarea) inside disabled element
This changes behaviuor to actially disable all sub-inputs of element but currently it just colorize inputs with patch #1, default behaviour is broken
Comment #6
andypostRe-roll for D8
Comment #7
andypostComment #8
valthebaldCould you please provide some tips on what is the problem and how patch solves it? I would like to review the patch, but don't know how to compare behavior before and after the patch
Comment #9
andypostCurrently the states system has ability to disable elements but actually no disable is happens (just a visual styling)
My patch tries to change his to actual disable of elements
Comment #10
valthebaldSince I don't see any viable way to make this part of any test, and patch looks fine, RTBC
Comment #11
webchickCommitted and pushed to 8.x. Thanks!
Marking for backport.
Comment #12
andypostRe-roll for D7
Comment #13
valthebaldSame as in 8.x
Comment #14
webchickCommitted and pushed to 7.x as well. Thanks!
Comment #16
Mac_Weber CreditAttribution: Mac_Weber commentedif the form
#type
is set to"hidden"
then it is not disabling. I tested changing the#type
totextfield
and it worked fine.Comment #17
David_Rothstein CreditAttribution: David_Rothstein commented@Mac_Weber, what do you mean exactly - are you saying this patch introduced a regression?
(I'm not sure the use case for client-side disabling of a hidden element, but maybe there's something I'm not thinking of.)
In any case, this fix looks a bit broader than the original issue title, so I'm changing that and also mentioning this in CHANGELOG.txt and the release notes.
Comment #18
Mac_Weber CreditAttribution: Mac_Weber commented@David_Rothstein the behavior before this patch is the same as after patching, regarding disabling hidden elements.
I have right now a use case I managed using custom JS to disable this element, yet it would be nice to use the Drupal API to do it. My use case: I have a checkbox which gives the use a option to send some facetapi filters or just make a whole new search. These filters in my use case are sent using hidden input, which I need to disable in order to clear them if the checkbox is unset.
Comment #19
David_Rothstein CreditAttribution: David_Rothstein commentedHm, interesting, thanks.
Since it doesn't seem directly related to the patch that was already committed in this issue, I think it would make more sense for you to create a new issue (feature request) for that functionality. That way it can start fresh as a separate issue. Of course feel free to post a link to it here, though.
Comment #20
Mac_Weber CreditAttribution: Mac_Weber commentedI opened a new issue #1834450: States API disabled state handler doesn't disable hidden input elements