Posted by peterpoe on August 29, 2011 at 2:29pm
8 followers
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | javascript |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | 7.17 release notes, FAPI #states, needs backport to D7 |
Issue Summary
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.
Comments
#1
Patch.
#2
hi, is this open or closed?
#3
This patch solves only a patch of trouble, the disabled element is DIV but disabled attribute affects only inputs
#4
Patch 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
#5
The last submitted patch, 1263302-states-disabled-d78-4.patch, failed testing.
#6
Re-roll for D8
#7
#8
Could 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
#9
Currently 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
#10
Since I don't see any viable way to make this part of any test, and patch looks fine, RTBC
#11
Committed and pushed to 8.x. Thanks!
Marking for backport.
#12
Re-roll for D7
#13
Same as in 8.x
#14
Committed and pushed to 7.x as well. Thanks!
#15
Automatically closed -- issue fixed for 2 weeks with no activity.
#16
if the form
#typeis set to"hidden"then it is not disabling. I tested changing the#typetotextfieldand it worked fine.#17
@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.
#18
@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.
#19
Hm, 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.
#20
I opened a new issue #1834450: States API disabled state handler doesn't disable hidden input elements