Display Bug when using #states (Forms API) with Ajax Request

Please review the patch to fix the above problem and needs to be integrated in to the main batch.

trying again with the patch instruction from http://drupal.org/node/3060/git-instructions/7.x

Can someone help on how to create a patch with git.
i followed the instruction from http://drupal.org/node/3060/git-instructions/7.x and named the patch as
[description]-[issue-number]-[comment-number].patch (comment 3). it does not work
and in comment 2 used
http://drupal.org/node/1054616 and named the patch [issue-number]-[description]-[comment-number]-D.patch
and this too did not work.
which of the two instructions are correct or did i miss something completely?

One more attempt...

Same problem.
Thanks, patch work for me.

removed spaces

wondering how that escaped...

Please make a patch against current 8-dev and use no D7 suffix to allow testbot run tests

EDIT Anybody can review this from performance side?

uploading 8.x ported patch

i pulled

git clone --branch 8.x http://git.drupal.org/project/drupal.git 

and created the patch, but it has failed. I tried with 8-dev & 8.x-dev, but got a warning that both 8-dev and 8.x-dev does not exist. pls advise on the branch to use for creating patch.

Testbot cant get your patch because of '(' in filename

so please reroll with a simple name like 1091852-multiple-states.patch

# wget http://drupal.org/files/issues/1091852-Display-Bug-when-using-states-(Forms-API)-with-Ajax-Request-10-D7.patch
bash: syntax error near unexpected token `('

@andypost: Thanks for your tip.

rerolling patch with clean name.

Linked this issue with original issue to get 2 review #557272: FAPI: JavaScript States system

Also a lot of thanx to @dannie-walker module that demonstrates this bug

Subscribe. Some time ago I created a general #states testing regimen at https://github.com/rfay/states_exercise . Last I looked at it a few things didn't look like they worked right at all, but I didn't pursue it.

sub.

I have a similar issue, but I'm actually replacing a number of elements which have #states attached.

Basically, there is a select and for each value, there is a checkboxes element which shows up for a option of that select. Based on yet another radios element, I'm replacing all checkboxes elements with another set of them (different values/labels). The reason for that is that a combined #states definition does not seem to work reliably, after clicking around it falls apart and shows both options or something like that.

Without this patch, all checkboxes elements show up initially but after changing the select, it works correctly. With this patch, this stops working completely.

The inline comments in the patch also need work, they shouldn't be longer than 80 characters, be real sentences with a dot at the end, start with an uppercase character and a space before.. e.g. "// This is a correct inline comment."

As Bendir I ran into the problems with the patch attached to #11. Without it after the first ajax call my js handler attached to document to 'state:required' event starts being called about a dozen of times on each value change of controlling select box. With this patch applied to D7.14 the state system seems to be totally disabled, no reactions on select box changes seem to occur.

I made some further experiments. Looks like the patch #11 works on D7.14 if corrected a bit.

+    new states.Dependent({
+      element: $(selector),
+      state: states.State.sanitize(state),
+      dependees: settings.states[selector][state]
+    });

here I had to replace 'dependees' with 'constraints'.

patch against drupal 7.x

Any plans to roll this into a D7 release?

This also works for our issues.

Last patch fails in our case. States event handler don't get re-binded to the AJAX-loaded elements, so it's impossible for other elements to depend on their state.

Last patch also not worked for me. I am doing same as mentioned in comment #26.

Weirdest thing, #24 worked in Chrome but not in Firefox, no errors to speak of though...

Weird for me... #24 doesn't work for me at all, even in Chrome.

I tested the patch #24 on Chrome 35 and Firefox 30. It works and I don't see how it could fail. Perhaps it was a browser cache problem?

I see, if you replace the element with AJAX the states are not applied to this element again.

I think was what committed in D8 don't works neither but this should be tested.

Not sure how to fix that.. Any idea?

The states are not initialized on AJAX-requests, as the initialization is blocked by states.Trigger by the code

    if (!this.element.data('trigger:' + this.state)) {
      this.initialize();
    }

The reason to this guard is stated in the code to be

Only call the trigger initializer when it wasn't yet attached to this element. Otherwise we'd end up with duplicate events.

I'll have to examine further why this is necessary and how to solve the problem.

I'm not sure adding a states.CreateState function that checks for duplicates is the optimal solution. Wouldn't adding a behavior.detach method, that removes all traces of removed states, be a cleaner solution?

Here's a patch that tries to solve the lack of initial states application after AJAX requests. In order to make it work without messing up the API (ie custom state callback function implementation), I have repurposed the dependee elements "triggered" data attribute. Instead of containing a flag whether or not the trigger has been initialized, it now contains the current value of that state for that trigger, and loads initial value from that when behaviors are attached.

This patch does not attempt to solve the issue with cleaning up orphaned dependants.

Oops, looks like a went a little trigger happy on the upload button.

Thanks for the patch, this is a very frustrating bug for me at the moment.

I have a had a quick try and it seems to work in most cases but I've found a case where it is still a problem.

I have an addressfield where one of the fields in it is shown/hidden with states based on a set of radios outside the addressfield.

Whenever I select a country and the addressfield ajax runs, my states controlled field appears, regardless of which radio button is selected.

It is possible that this may be some other unrelated issue so I will investigate further.

Strange. I've done nothing since my last test but now it is working even for the addressfield case.

I will report back if it stops working again.

Not sure if it's just me but I'm having problems when I have ajax that loads new fields that weren't originally on the form or removes fields from the form that have states.

Initially I was getting these errors:

TypeError: this.element.data(...) is null

for line 319 of states.js:

if (!this.element.data().hasOwnProperty('trigger:' + this.state)) {

Just to see what would happen (since I don't yet have much knowledge of how it all works) I changed it to:

        if ($dependee.data() !== null && $dependee.data().hasOwnProperty('trigger:' + state.name)) {

and it fixed the error, after which states are working for fields that were always on the form but not for ones that were added via ajax.

(this is unrelated to my previous addressfield ramblings.)

Related issue #2226405: FAPI #states: dependent element added via AJAX initializes incorrectly if dependee has been initialized earlier

It turned out I had some other bugs that were causing states to not work on new form elements added by my ajax, however the "TypeError: this.element.data(...) is null" bug remains.

I now have this working successfully with my form, which is a pretty good use case of a large drupal commerce checkout form that has a complex set of visibility and required field states, a lot of form alters, custom ajax and custom javascript.

I will roll an updated patch with my fix for the is null bug.

Updated patch.

I assume this is also going to need new tests.

[edit] Damn, I forgot to re-check the comment number before I posted.

I am having a problem with a Javascript multi-page FAPI form when wrapped in ctools so as to bring up a modal dialog. The page advance just hides fieldset(s) using the #states triggered by a hidden field. It works before bringing up the modal dialog, but after bringing up and dismissing the modal dialog, the HTML field the selector specifies changes, but the #states do not hide/show their fieldsets(s). trigger() is explicitly being called on the tag using the selector, plus it works before the modal is opened/closed.

Initially my problem sounded like this bug #1592688: #states can cause the form "required" mark to appear more than once on the same element. Feeling in luck since the new 7.40 release was rolled out yesterday, I upgraded. Unfortunately, it did not fix it. So I cloned the git repo, branched 7.40, applied the above drupal-states_after_ajax-1091852-39.patch, and copied states.js up to the server. No change in behavior. Now David_Rothstein patch was also to the states.js file, but obviously to 7.39. Would this make a difference? The patch appeared to apply cleanly. Thank you.

A similar (or the same) problem seems to be happening with D8 as well. I'll test the patch (and adapt it where need it) on D8 and report back.

This is definitely an issue in D8.
The D7 fix (manually applied) doesn't work for me in D8 and would need to be tweaked/fixed.

(removed duplicate post)

Ideally this should be fixed in D8 first (where I believe we can also now add tests for this).

Confirm that patch from #40 works perfect for 7.50 on my current project.

This also applies to Drupal 8 per #44, so assigning this to 8.x per the backport policy.

Possibly we already have an existing issue for this?

I created a module that provides a temporary fix for those that does not want to patch the core and wait until this fix gets merged: https://www.drupal.org/sandbox/nbouhid/2776183 (D7)

We're using it and it works fine.

Thanks nbouhid! Working as advertised. I've got a doublefield showing both fields if different field A is X and only one field if A is Y. The old states.js showed both fields even when A is Y after adding another item. The new states.js fixes this.

For anyone using patch #40 or the sandbox project created by @nbouhid for Drupal 7, there are two critical errors. CKEditor fails to load every time in a ctools popup window (such as for Panels) due to these lines of code:

if ($dependee.data() !== null && $dependee.data().hasOwnProperty('trigger:' + state.name)) {

if (this.element.data() !== null && !this.element.data().hasOwnProperty('trigger:' + this.state)) {

The error generated by the console is as follows, pointed at $dependee.data() and !this.element.data(), respectively:

Uncaught TypeError: Cannot read property 'hasOwnProperty' of undefined

It does not matter if using the CKEditor or WYSIWYG modules, it fails in both cases. Rolling back the patch fixes the problem.

Attached is an updated patch for review that checks if the objects are defined. Thanks.

#57 is a good addition!

I was getting the AJAX + states display bug and #40 fixed it, but I was getting Uncaught TypeError: Cannot read property 'hasOwnProperty' of undefined which was fixed by #57.

Thanks #57 helped me, but it's on Drupal 8.2, so I have updated it for Drupal 8.3.

@kalistos, patch #57 is not Drupal 8.2. It is for Drupal 7.

Closed #2864632: Form states not working when form loaded via ajax? as a duplicate

Patch in #60 doesn't apply to 8.4.x since the move to es6 for all javascript.

First a re-roll. Not setting to needs review as I'm currently also doing some small changes, but for this an interdiff would be good.

1. +++ b/core/misc/states.es6.js
   @@ -146,10 +148,16 @@
   +          $dependee.bind(`state:${state}`, { selector, state }, stateEventHandler);
   

   Why change from on to bind?
   Unnecessary change in my mind.

2. +++ b/core/misc/states.es6.js
   @@ -146,10 +148,16 @@
   +          if (typeof $dependee.data() !== 'undefined' && $dependee.data() !== null && $dependee.data().hasOwnProperty('trigger:' + state.name)) {
   
   @@ -368,7 +376,7 @@
   +      if (typeof this.element.data() !== 'undefined' && this.element.data() !== null && !this.element.data().hasOwnProperty('trigger:' + this.state)) {
   

   Don't like this, to much clutter :/

   This is also not needed in my mind. As we just can check for undefined. jquery data does the rest.

Changes applied.

Small issue on the second change from #68. For second occurrence it needs to be checked for equals undefined.

Also adding patch for 8.4.x if anybody else needs it (we do)

Tested this with 8.4.x and seems working fine.
Tested with nested paragraph and related #states logic, works fine with paragraphs as well.

We need a JavascriptTestBase test for this. We can now test javascript interaction in D8 so a failing test without the fix and a passing test with the fix would great.

Patch from #70 works great on 8.5. Thanks!!

The patch in #70 needs a reroll after #2917234: [2/2] JS codestyle: no-restricted-syntax was committed.

Reroll after the following issues were committed:
- #2981652: [Aug. 9 2018] Format core JavaScript using recently add Prettier
- #2917234: [2/2] JS codestyle: no-restricted-syntax

Still needs a tests to show the current failing behavior.

Just to mention that the patch #40 fixed my issue on a d7.60.

Updated core from 8.5 to 8.6.3. Patch #70 applied cleanly on 8.5 but does not apply cleanly on 8.6.3.

Re-rolled again because the compiled version no longer applied.

HEAD was broken...

Posting this here as it's relevant to an issue I ran into recently.

These patches work great. However, it also seems to conflict in an odd way with the Webform module. Nothing that's terribly bad, but definitely noticeable. Related issue thread:
https://www.drupal.org/project/webform/issues/2996530

Again, not sure if this is actionable, but might be of interest if anyone else notices this!

The issue reported in #83 in the Webform module has been resolved, see #2996530: AJAX Settings visibility state based on non-existing DOM element

The webform module evaluated the visibility of a container on the value of a non-existing DOM element. Currently, this is evaluated as 'visible' but after applying the updated States logic implemented here this evaluates as 'invisible'. It was solved by removing the visibility states implementation.

Updated core from 8.3.9 to 8.6.7. Patch #60 works on 8.3.9 but does not applied on 8.6.7.
message was could not apply patch while update core.

@mukun: I'm currently applying patch #80 with Drupal 8.6.7, and it's applying cleanly. Might wanna try that out!

Patch from #80 on Drupal 8.6.13 and PHP 7.2.15 works great. Thanks!

I had the same issue (#states not working after an AJAX call) and patch #80 fixed the issue.

Tested on Drupal 8.6.13.

In order to make a test, it would help to have clear steps to reproduce.

@jonathanshaw: To replicate the bug, you need a content type with a field that makes an AJAX request and another field that has a state dependent on that field. In my use case, I have a content type with an image field and a text field that should only show when an image has been uploaded.
1. Have a content type with an image and a text field
2. Create a custom module that adds a state to your text field to only display when the image field has value. It would look something like this:

use Drupal\Core\Form\FormStateInterface;

function mymodule_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  if ($form_id == 'node_page_form' || $form_id == 'node_page_edit_form') {
    $form['field_my_text_field']['#states'] = [
      'visible' => [
        ':input[name="files[field_my_image_field_0]"]' => ['filled' => TRUE],
      ],
    ];
  }
}

3. Go to your content type and upload an image. You would expect to see field_my_text_field because the image field has an image and the state should react to the AJAX call. However, you won't see field_my_text_field. Save your node, and go back to edit your node. Now you should see field_my_text_field.
4. Apply the patch from #80 and go through the steps again. Now on step 3, you should see field_my_text_field immediately after you upload an image.

I have added a test based on module from #18 to #2702233-80: [backport] Add JavaScript tests for Form API #states: required, visible, invisible, expanded, checked, unchecked

The patches add a test to the patch from #80. As Form State API tests are being developed in #2702233: [backport] Add JavaScript tests for Form API #states: required, visible, invisible, expanded, checked, unchecked, I extended the patch from #2702233-76: [backport] Add JavaScript tests for Form API #states: required, visible, invisible, expanded, checked, unchecked with a test based on module from #18.
Uploaded patches contain:
1091852_with_2702233-full.patch - patches from current issue #80, #2702233-76: [backport] Add JavaScript tests for Form API #states: required, visible, invisible, expanded, checked, unchecked, and the test for current issue. It should pass tests.
2702233-80.patch - tests from #2702233-76: [backport] Add JavaScript tests for Form API #states: required, visible, invisible, expanded, checked, unchecked extended with the test for the current issue, but without the patch for the current issue. This should fail through testing.
1091852-93.patch - patch from #80 and test for it, applied over #2702233-76: [backport] Add JavaScript tests for Form API #states: required, visible, invisible, expanded, checked, unchecked. This should even fail applying to 8.8.x until the latter patch is committed.

It would help to get a JS maintainer to look at this now.

I've tested https://www.drupal.org/files/issues/2019-09-12/1091852_with_2702233-full... and it applies cleanly and resolves my issue.

https://www.drupal.org/files/issues/2019-09-12/1091852-93.patch against 8.7.10 does not apply.

Thanks for the work on this issue.

UPDATE https://www.drupal.org/files/issues/2019-09-12/1091852_with_2702233-full..., introduces a regression where the revision log field is hidden when new nodes are created. Is this intended behavior?

Hi,

I have applied the patch #93 with 8.9x and it failed to apply.

I have made it compatible with 8.9x.
And there was some error as per Drupal coding standard I have solved that too and uploaded the patch with interdiff.

After that, I have tested the patch and it worked as design.

Below are my updates.

1). I have added the text field in the article content type.

2). I have made it dependent on the image field using hook_form_alter().

Before applying the patch
The text field didn't show after uploading the image. Below is the output screenshot.

After applying the patch
The text field did show after uploading the image. Below is the output screenshot.

The patch is working great.

Thanks,
Ren

We've identified that this actually causes a regression with the "Revision log message" field on new nodes. Because it has a state that is dependent on the revision checkbox being checked, and on new forms this checkbox is not in the form at all, the revision log field is hidden when it should not be. I've included a change that fixes this to add the state conditionally in ContentEntityForm. But this will need test coverage to ensure it does not break. As such I'm marking this as Needs work for now.

Patch #104 is working for us in 8.8.x

Patch #104 solves a slightly different issue for me on 8.8.x.

I have an entity form that includes a Media Library widget. It includes a second field whose #states depend on the value of a third field. If I load the form and click "Add media", the #states on the second field no longer work, despite the Media field not being involved in the #states at all. I think the patch fixes my issue because of its care to not to call the state changes multiple times.

I'm coming from #3114741: [#States API] AJAX and Conditionals Conflicting and can confirm that patch #104 resolves this and multiple related issues with the Webform module, states, and AJAX. I'm currently on Drupal 8.8.2.

Tested #104, works great, I also added the 7.2 and 7.3 env tests, green.
Patch has great tests and interdiff, what are we waiting for ?

Per #104 this needs a little more test coverage, so cannot be RTBC

I'm seeing similar issues to this when using #states for conditional field logic on node forms, although instead of the ajax coming from a custom form like in this issue, the ajax would be from paragraphs with its edit links.

On typical node add and node edit forms, it's working great.

But, in my site, I have a case where via paragraphs, there is an entity reference field using entity browser, that allows users to edit the referenced entities within the entity browser, and when clicking the Edit link the first time, the #states work. But if i close that window and try to Edit another reference node in there, the #states does not work.

Here is my #states code

if ($form_id == 'node_detail_page_form' || $form_id == 'node_detail_page_edit_form') {
    $form['field_alternate_title_url']['#states'] = [
      'invisible' => [
        ':input[name="exclude_node_title"]' => ['checked' => TRUE],
      ],
    ];
}

I also tried this patch and it did not solve the issue.

See screenshot - https://www.drupal.org/files/issues/2020-07-01/Screen%20Shot%202020-07-0...

Reroll for 9.1.x

Reroll for 9.0.x based on #115

102 worked for 8.9! Hurray!

#104 resolved our issue on 8.9.13.

Here's a reroll, both for 9.1, and HEAD of 9.2.

Someone definitely needs to check these tests. I know a little about PHP tests, and nothing about JS tests. I hope I didn't mangle them.

The drop is always moving. Here's another reroll to catch up to HEAD, and to fix the linting issues.

But again, someone who understands JS tests needs to review the tests.

When you reroll, please check that the patch size stays roughly the same. We lost about half the patch (all the new test coverage) between #115 and #116. So please reroll but base this on a version that still contains everything please.

I think the confusion in the tests is because much of it was committed in at least three other issues:
https://git.drupalcode.org/project/drupal/-/blame/9.2.x/core/tests/Drupa...
https://git.drupalcode.org/project/drupal/-/blame/9.2.x/core/modules/sys...

But we did seem to loose

• \Drupal\FunctionalJavascriptTests\Core\Form->testAjaxJavascriptStates()
• All the additions to core/tests/Drupal/FunctionalJavascriptTests/JSWebAssert.php
• All the additions to core/modules/system/tests/modules/ajax_forms_test

We'll need to get those back before this is commitable.

Following @Lendude and @dalin comments, this is my attemp to reroll the patch from #115 (so we don't loose what @dalin mentioned) to catch up with 9.2.x.

The JSWebAssert changes were removed on purpose in #2702233: [backport] Add JavaScript tests for Form API #states: required, visible, invisible, expanded, checked, unchecked, see comments #105 -> #109

Attached updated the assertions in \Drupal\FunctionalJavascriptTests\Core\Form\JavascriptStatesTest::testAjaxJavascriptStates() method to match the other assertions in the file.

This patch solves a related but different issue for me: if fields are dynamically added to the form by an AJAX call, which have #states (depending on a form item that was present already)... those #states are not applied.

Before I started messing with the JS, I added tests for that situation.

Disclaimer: I cannot properly review this because I'm not a JS developer; I only get half of the code.

But I noticed that

+++ b/core/misc/states.js
@@ -240,15 +246,9 @@
-      states.postponed.push($.proxy(function () {
-        this.element.trigger({
-          type: "state:".concat(this.state),
-          value: oldValue,
-          oldValue: null
-        });
-      }, this));

...removes the only code that changes states.postponed. So if this is the right way of doing things, we should remove any reference to states.postponed.

Tried that; the tests still succeed.

My biggest question now is: are we even allowed to essentially replace this whole states.postponed.push() mechanism with the single call to this.reevaluate() in states.Dependent?

I'm thinking it wasn't there for nothing. It feels like

• either it prevented reevaluate() from being called on the dependent objects too many times,
• or it prevented calling reevaluate() when 'things' may not be fully initialized yet.

I'm guessing it's the second. I'm guessing this 'postponed' mechanism had a good reason for being there. But this JS makes my head spin so I can't answer that.

(I tried reverting the removal of the above code + addition of the this.reevaluate() call, but that made things fail again.)

PHPCS + Yarn + CSpell...

So summarizing, AFAICT this needs

• Per #104: test coverage to make sure that the ContentEntityForm.php change doesn't break in the future? (I guess this means, show an entity revision form when $form['revision']['#access'] == FALSE, and ensure the log message element is visible - which would currently break in HEAD? Possibly to be broken out into a separate issue if someone thinks that speeds things up...)
• A good review including an opinion/answer on the question in #131.

It sounds like #104 could be triggered by a form alter anyway, even without this issue. In which case, yes it's a good candidate for handling as a separate issue. I'm happy to do reviews on that issue if you'll code it.

Given this is an old, major bug that's proven difficult to fix, I think it's reasonable to ask for a js maintainer's review. Which may answer #131.

I've cleaned up patch #132 (there was a .rej file presumably from a previously failed patch which I have removed) and put it into a merge request so that any changes can be more easily added.

I attempted to add the tests mentioned in #104 and #134 and am wondering whether it would be better to break those out elsewhere. Ideally we need a test entity with revisions enabled in order to test the revision log message field does not disappear after an AJAX request. Core does have the entity_test_revlog entity with revision logging enabled, but there are no forms and routes configured that are accessible to the javascript functional tests. So should testing that functionality live with the entity_test tests, or still within the Javascript state tests. I'm happy to try again with the tests, but not sure as to the desired approach. Thoughts welcome.

I attempted to add the tests mentioned in #104 and #134 and am wondering whether it would be better to break those out elsewhere.

I think so

Core does have the entity_test_revlog entity with revision logging enabled, but there are no forms and routes configured that
are accessible to the javascript functional tests.

Sounds like we'll need to add them.

So should testing that functionality live with the entity_test tests, or still within the Javascript state tests.

Seems like this is really an issue with the revision logging, not generically with the javascript states. So entity_test... I'd say.

Yes, it feels like testing that part is best off connected to 'whatever else Core has in that area' (entities, revisions, I'm not aware of the setup of those tests personally). And doesn't need to be tied in with the JS + its tests at all.

Patch #104 seems to be working fine in my use case where #states would not initialize after ajax request.

https://www.drupal.org/project/drupal/issues/1091852#comment-11611711

I have an issue with Views Bulk Operations (VBO) module when there is only one option that you can modify in bulk, for example when you want to modify values of a reference field of nodes.

In this case this one option will be hidden

, because the "show value" checkbox is changed to "#type = 'value'"

https://git.drupalcode.org/project/views_bulk_operations/-/blob/7.x-3.x/...

  // If the form has only one group (for example, "Properties"), remove the
  // title and the fieldset, since there's no need to visually group values.
  $form_elements = element_get_visible_children($form);
  if (count($form_elements) == 1) {
    $element_key = reset($form_elements);
    unset($form[$element_key]['#type']);
    unset($form[$element_key]['#title']);

    // Get a list of all elements in the group, and filter out the non-values.
    $values = element_get_visible_children($form[$element_key]);
    foreach ($values as $index => $key) {
      if ($key == 'show_value' || substr($key, 0, 1) == '_') {
        unset($values[$index]);
      }
    }
    // If the group has only one value, no need to hide it through #states.
    if (count($values) == 1) {
      $value_key = reset($values);
      $form[$element_key]['show_value'][$value_key]['#type'] = 'value';
      $form[$element_key]['show_value'][$value_key]['#value'] = TRUE;
    }
  }

and when "this.reevaluate();" runs in "states.Dependent = function (args) {" then it hides it because i think the dependency is not in the html.

misc/states.js:48

states.Dependent = function (args) {
  $.extend(this, { values: {}, oldValue: null }, args);

  this.dependees = this.getDependees();
  for (var selector in this.dependees) {
    this.initializeDependee(selector, this.dependees[selector]);
  }
  // Reevaluate to execute initial states.
  this.reevaluate();
};

I have a proposal for the fix, but i am not sure this is the right one and covers all cases. I think we should check if at least one selector exists in the html and if yes we call the "this.reevaluate()" function only in this case.

states.Dependent = function (args) {
  $.extend(this, { values: {}, oldValue: null }, args);

  this.dependees = this.getDependees();
  for (var selector in this.dependees) {
    this.initializeDependee(selector, this.dependees[selector]);
  }
  // Reevaluate to execute initial states.
  // Check if there is at least one selector in the html.
  for (selector in this.dependees) {
    if ($(selector).length) {
      this.reevaluate();
      break;
    }
  }
};

As i see this affects Drupal 8 & 9 too.

I made a patch based on https://www.drupal.org/files/issues/drupal-states_after_ajax-1091852-57.... for VBO issue(https://www.drupal.org/project/drupal/issues/1091852#comment-14225149).

I made a patch based on https://www.drupal.org/files/issues/drupal-states_after_ajax-1091852-57....

Was there a reason you didn't use the latest version as discussed in #141?

Additionally, it helps enormously if you can provide an interdiff.

@jonathanshaw

Was there a reason you didn't use the latest version as discussed in #141?

Why would i have used that patch? when i fixed the d7 version not the Drupal 8&9 version. I made the diff though.

I'm re-rolling the patch to be able to apply to a 9.1.x core version, I also removed a couple of duplicated files and tests, for now I just need to apply the code change.

Work fine.

JavaScript linting is failing.

+1 for #150

Fixed CS issues.

#155 seems to fix the issue for me

NW for #142 test tidy up.

#155 is working for me

#155 and MR749.diff works for me, but there is an another (maybe separate?) issue:
I'm using paragraphs on modal and using same machine name for fields with states on parent node and in paragraphs too. Because of the same field machine name, states on modal doesn't work only on the parent node form. If I use separate field machine names, the states works in parent node form and in paragraphs modal form too.

I'm having a similar issue with an ajax callback applied element on one of our webforms and confirmed that the patch #155 fixes my issue.

However, I'm seeing some regressions on the form after applying the patch due to using multi wizard page on the form.

We have a select element on wizard page 2 and its visible condition is depending on another element which only exists on the wizard page 1.

After applying the patch, the select element on wizard page 2 is no longer visible regardless what value we have on the element of wizard page 1.

Our solution for now is to create a form alter to make the element on wizard page 1 visually hidden on wizard page 2 so that the value could be
respected by the select element on wizard page 2.

Due to this issue, we have to thoroughly review all other webforms we have on the site that use multi wizard page.

I've re-rolled the patch in #155 on the 9.5x branch.

I'm not able to apply patch #163 with Drupal 9.5 with error, `patch fails to apply`.

Sorry, I've made a mistake checking our build output. Putting back into needs review

Fixed CCF for #163 for 9.5.x.
Please review.

Rerolled patch for 9.5 because it wouldn't apply.

Another attempt to reroll #155.