Problem/Motivation
The event handler listening for state:disabled never gets triggered.
Steps to reproduce
Create a simple form with a checkbox and a Chosen select whose enabled states depends on the checkbox.
$form['enabler'] = [
'#type' => 'checkbox',
'#title' => 'Enable',
];
$form['selecter'] = [
'#type' => 'select',
'#title' => 'Select',
'#chosen' => TRUE,
'#options' => [
'foo' => 'Foo',
],
'#empty_option' => '- Empty -',
'#states' => [
'enabled' => [
':input[name="enabler"]' => ['checked' => TRUE],
],
],
];
While the actual select element gets its disabled attribute toggled by the checkbox, the Chosen select starts out and always remains enabled.
Proposed resolution
The states events are triggered via jQuery (both in 10.5.x and in 11.x). jQuery only calls jQuery event handlers and native event handlers specified through the onevent attributes (both in 3.7.1 and 4.0.0-rc.1). As this module's event handler is added through the native addEventHandler method as of 5.0.2, it never gets called by jQuery.
My proposed solution is to add back to jQuery dependency and listen for state:disabled with a jQuery event listener.
Remaining tasks
Maybe there is a way to dynamically detect when #states or jQuery is used, and only add the event listener in that case.
User interface changes
None.
API changes
None.
Data model changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 3541083-9.patch | 1.38 KB | nagy.balint |
Comments
Comment #2
avpadernoComment #3
nagy.balint commentedHi!
I think that 5.x will remain native and we will not reintroduce jQuery there.
Comment #4
nagy.balint commentedComment #5
nagy.balint commentedAs far as I saw core is also moving away from jQuery, so I think we will need a solution without jQuery.
Comment #6
castanearieCore is indeed in the process of moving away from jQuery, but so far states.js is still using jQuery.trigger, even in that ticket's branch. Maybe it's possible to dynamically detect when states.js is loaded and add the jQuery event listener only then?
Comment #7
eric_a commentedGiven that this bug report has priority "Normal", I was wondering if this is considered an edge case that only happens with special custom forms or if this is a problem with many normal use cases?
How many things could break when updating from 4.0.3 to v5 in different categories of standard websites with for example webforms and paragraphs?
Comment #8
nagy.balint commented@eric_a
A site using Chosen on fields whose enabled/disabled state is controlled via #states can hit it.
Maybe we can use MutationObserver on the original select's disabled attribute.
Comment #9
nagy.balint commentedHere is a patch which seems to work for disabled state with MutationObserver.
Comment #11
nagy.balint commented