- Issue created by @Ashley George
- ๐ฎ๐ณIndia shiv_yadav
Hi Ashley George,
Please use this type of coding after working for me visible functionality .
shared coding format:$form['select1'] = [
'#type' => 'select',
'#title' => 'Select 1',
'#options' => [0 => 0, 1 => 1],
'#default_value' => 0,
];$form['select2'] = [
'#type' => 'select',
'#title' => 'Select 2',
'#options' => [0 => 0, 1 => 1],
'#default_value' => 0,
];$form['select3'] = [
'#type' => 'select',
'#title' => 'Select 3',
'#options' => [0 => 0, 1 => 1],
'#states' => [
'visible' => [
[':input[name="select1"]' => ['value' => 0]],
'and',
[':input[name="select2"]' => ['value' => 1]],
],
],
]; - Status changed to Needs review
about 1 year ago 1:46pm 21 September 2023 - Status changed to Postponed: needs info
about 1 year ago 2:38pm 25 September 2023 - ๐บ๐ธUnited States smustgrave
@Ashley George does that answer your question? If so this can be closed.
- ๐ฌ๐งUnited Kingdom Ashley George
@smustgrave unfortunately this doesn't seem to resolve things. After implementing the change suggested by @shiv_yadav the visibility on "select3" is now only linked to "select1". So I beleive there is still a valid issue here.
- Status changed to Active
about 1 year ago 4:05pm 28 September 2023 - Status changed to Needs review
about 1 year ago 4:06pm 28 September 2023 - ๐ฌ๐งUnited Kingdom Ashley George
Actually I'm not quite right with my description of how it's behaving now, but it's still not correct. If someone could see if they can replicate that would be awesome.
- Status changed to Active
about 1 year ago 7:52pm 29 September 2023 - ๐บ๐ธUnited States smustgrave
I can confirm the issue you are seeing. I'm not entirely sure the cause.
At first I thought maybe states wasn't picking up the default value from select1 but that kinda is disproved by switching select2 to 0 and 1 again. Which triggered select3
Believe this is a valid bug, moving to Active for a patch/tests.
- First commit to issue fork.
- Merge request !7045Update drupal.js: Modules like big_pipe invoke attachBehaviors that results in... โ (Closed) created by sukr_s
- Status changed to Needs review
9 months ago 6:03am 15 March 2024 - ๐ฎ๐ณIndia sukr_s
Modules like big_pipe invoke attachBehaviors that results in multiple attachment of behaviors for a given context. So maintain semaphore to ensure that the behavior is attached only once.
If the attachBehavior is called multiple times, then in states multiple states.Dependent objects are created for the same elements. However the initialise is not called in Trigger function for all the states.Dependent object since it checks if it was already initialised for an element. Therefore it's best to avoid multiple invocation of attachBehaviors to ensure that the behviors work as intended.
This fix ensures that attachBehavior is called only once for a given context
- Status changed to Needs work
9 months ago 12:13pm 15 March 2024 - ๐บ๐ธUnited States smustgrave
Will need a test to show the bug.
Also issue summary appears incomplete, recommend using standard issue template
- ๐ป๐ณVietnam phthlaap
phthlaap โ changed the visibility of the branch 3386191-states-not-working to hidden.
- ๐ป๐ณVietnam phthlaap
phthlaap โ changed the visibility of the branch 3386191-states-not-working to active.
- ๐ป๐ณVietnam phthlaap
phthlaap โ changed the visibility of the branch 3386191-9x-states-not-working to hidden.
- Status changed to Needs review
9 months ago 4:14pm 18 March 2024 - Status changed to Needs work
9 months ago 4:26pm 18 March 2024 - Status changed to Needs review
9 months ago 4:41pm 18 March 2024 - ๐ฎ๐ณIndia sukr_s
@phthlaap the fix that you have provided is very specific to #states. The duplicates loading of attachBehavior can cause problems for any other module or custom module. So it's best to fix the root cause rather than in the affected module. Enclosed in a patch with tests for the same using #states for testing.
- Status changed to Needs work
9 months ago 2:13pm 19 March 2024 - ๐บ๐ธUnited States smustgrave
If a different approach is being proposed can a separate MR be opened for reviewing. Issue summary will eventually have to be updated to match.
- Merge request !7100Apply patch 3386191-11x-states-not-working.patch โ (Closed) created by phthlaap
- Status changed to Needs review
9 months ago 3:10pm 20 March 2024 - ๐ป๐ณVietnam phthlaap
The approach in patch #26 will affect some tests because I believe Ajax should reattach on form submission once again.
- Status changed to Needs work
9 months ago 11:50am 25 March 2024 The Needs Review Queue Bot โ tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide โ to find step-by-step guides for working with issues.
- Status changed to Needs review
9 months ago 4:27pm 25 March 2024 - Status changed to Needs work
9 months ago 5:07pm 25 March 2024 The Needs Review Queue Bot โ tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide โ to find step-by-step guides for working with issues.
- ๐ป๐ณVietnam phthlaap
phthlaap โ changed the visibility of the branch 3386191-states-not-working-drupaljs to hidden.
- Status changed to Needs review
9 months ago 4:49am 26 March 2024 - Status changed to Needs work
9 months ago 5:27am 26 March 2024 The Needs Review Queue Bot โ tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide โ to find step-by-step guides for working with issues.
- ๐ป๐ณVietnam phthlaap
As suggestion of @nod_ , I use Once library to fix the issue. I think it is better.
I also changed the variable name $states because it is no longer a jQuery instance. but, it will be identical to the state variable defined at the top of the file, so I named it element. - Status changed to Needs review
9 months ago 3:38pm 1 April 2024 I have tested the last changes and I can confirm it's working.
I'm also adding a patch for the 10.1.6 core version.- Status changed to Needs work
9 months ago 3:57am 3 April 2024 The Needs Review Queue Bot โ tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide โ to find step-by-step guides for working with issues.
- Status changed to Needs review
9 months ago 4:05am 3 April 2024 - ๐จ๐ดColombia Ozle Bogotรก
I fixed this issue modifying only the $states variable to
const $states = once('states', '[data-drupal-states]', context);
- ๐บ๐ธUnited States smustgrave
@ozie can you try with tests though. Would have to be an MR
- ๐ป๐ณVietnam phthlaap
@smustgrave
The merge request above are already using same solution once library and also have a tests https://git.drupalcode.org/project/drupal/-/merge_requests/7045/diffs
- ๐บ๐ธUnited States smustgrave
MR also has additional changes besides that one line
- ๐ป๐ณVietnam phthlaap
As comment #40 I has explained, the variable name $states is no longer a jQuery instance. but, it will be identical to the state variable defined at the top of the file, so I named it element.
- Status changed to RTBC
7 months ago 2:09pm 28 May 2024 - ๐บ๐ธUnited States smustgrave
Removing the 2nd approach to avoid confusion
1) Drupal\FunctionalJavascriptTests\Core\Form\JavascriptStatesTest::testJavascriptStates Failed asserting that false is true. /builds/issue/drupal-3386191/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:121 /builds/issue/drupal-3386191/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:55 /builds/issue/drupal-3386191/core/tests/Drupal/FunctionalJavascriptTests/Core/Form/JavascriptStatesTest.php:454 /builds/issue/drupal-3386191/core/tests/Drupal/FunctionalJavascriptTests/Core/Form/JavascriptStatesTest.php:71 /builds/issue/drupal-3386191/vendor/phpunit/phpunit/src/Framework/TestResult.php:728 FAILURES! Tests: 1, Assertions: 203, Failures: 1.
Shows test coverage
Believe the change makes sense using once()
- Status changed to Needs review
7 months ago 10:00pm 28 May 2024 - ๐ฆ๐บAustralia larowlan ๐ฆ๐บ๐.au GMT+10
Hi folks
Can we get an issue summary update that details why using once is the solution here.
Its not evident to me why that makes things different or why bigpipe is part of the issue.
Fine to self RTBC afterwards.Thanks
- ๐ฎ๐ณIndia sukr_s
@Iarowllan the analysis was provided in #14. Copying the same below for convenience.
Modules like big_pipe invoke attachBehaviors that results in multiple attachment of behaviors for a given context. So maintain semaphore to ensure that the behavior is attached only once.
If the attachBehavior is called multiple times, then in states multiple states.Dependent objects are created for the same elements. However the initialise is not called in Trigger function for all the states.Dependent object since it checks if it was already initialised for an element. Therefore it's best to avoid multiple invocation of attachBehaviors to ensure that the behviors work as intended.
- Status changed to RTBC
7 months ago 8:12pm 5 June 2024 - Status changed to Fixed
6 months ago 8:04pm 13 June 2024 - ๐ซ๐ทFrance nod_ Lille
Committed and pushed 5e2806f1b5 to 11.x and e3b6f2fd67 to 11.0.x and b02bce4af0 to 10.4.x. Thanks!
- ๐ซ๐ทFrance eddylbs Paris
Hello,
Patch from #46 works for me on 10.2.4
Thanks Automatically closed - issue fixed for 2 weeks with no activity.
We have a report of a regression caused by this. I don't know whether this should actually be fixed in Webform. Perhaps the people on this issue can look into it.
- ๐ฎ๐ณIndia gaurav_manerkar Vasco Da Gama, Goa
We are facing issue because of this change. Conditional #states JS are not getting replied when element is refreshed/rendered by JS
- ๐ฎ๐ณIndia sukr_s
see related issue ๐ JS #states behavior does not have a detach method Needs review