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

Another attempt to reroll #155.

Fixed CCF, attached interdiff for same. Please review

The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

#172 applies and works in 9.5.3

#172 applies and works in 9.5.5. Thanks!

Patch #172 works for me with a Drupal 9.5.9

Fix patch for Drupal 10.1.x

The last submitted patch, 177: 1091852-177.patch, failed testing. View results →

Having Issues with #132 ( → ) , It gives an errors on page load where we use #states attributes in fields. This may cause the page load js errors and not recommend to use it . Thank You !!!

I've tested Drupal 10.1 with a clean install using the steps in the description to reproduce the issue and I'm not able to reproduce it. This seems to have been fixed in states.js for Drupal 10.

Patch #172 works for me with a Drupal 9.5.8

I can no longer replicate this issue on Drupal 9.5 or 10 and I think the fix in #1988968: Drupal.ajax does not guarantee that "add new JS file to page" commands have finished before calling said JS → core issue, but I haven't been able to confirm that. I think we need someone to provide a reproducible scenario (I used the one in the issue description, and I could no longer reproduce it) or possibly close this as fixed. I do wish I knew exactly what core issue seems to have resolved it, I don't feel easy closing this until we know.

I'm still having this issue on a form submit button whose state depends on some facets elements. #177 resolves the issue for me. I'll try to produce a trimmed down reproducible scenario like the one I'm experiencing soon™.

I can also confirm I'm still having this problem on 10.1.
Applying #177 resolved it for me.

Rerolled #177 for 10.2.

Confirm I'm still having this problem on 10.2.
Applying #186 resolved it for me.

@robin.houtevelts @keshavv steps to reproduce - or at least come comments on the circumstances in which you're encountering this bug - would be really helpful.

I'm still having what I think is the same issue and the latest patch does not fix it. Perhaps this is a slightly complicated example, but I will simplify it as best as possible.

Here I have I two select lists. The first one uses an ajax callback to modify the options contained within the second one, which has a couple hardcoded default values:

$form['billing_date'] = [
  '#type' => 'select',
  '#title' => t('Billing Month'),
  '#options' => $options,
  'callback' => '::equipmentUpdate',
];

$form['equipment'] = [
  '#type' => 'container',
];

$form['equipment']['equipment_id'] = [
  '#type' => 'select',
  '#title' => t('Equipment Number'),
  '#options' => [
    0 => '- Select - ',
    'other' => 'Enter manually'
  ],
];

My custom equipmentUpdate callback does a lot of other things, but here is the command I use to update the options of the second select list:

$response->addCommand(new ReplaceCommand('#edit-equipment .form-item-equipment-id', $equipment)

This ReplaceCommand occurs after $equipment (which is a copy of $form['equipment']['equipment_id']) has been modified to add new values after the two defaults set earlier.

That functionality works just fine, but what does not is the state of a third field, whose visibility depends on a value contained within the second select list, which is modified by the ajax call:

$form['equipment']['equipment_id_other'] = [
  '#type' => 'textfield',
  '#title' => t('Equipment Number'),
  '#states' => [
    'visible' => [
      ':input[name="equipment_id"]' => [
        'value' => 'other'
      ],
    ],
  ],
];

Before the ajax callback, the visibility of this text field is correctly controlled by the equipment_id select list. After the callback completes, this no longer works, and the visibility of this field does not change. I have tested by experimenting with other ways of organizing the data and using different ajax commands, like HtmlCommand, but nothing works. No matter what I do, subsequent ajax calls continue to correctly modify the select list values, but the visibility state of the text field is broken.

I have confirmed that all the markup in all fields and wrappers are exactly the same before and after the ajax command, except that that ajax operation changes element ids, for example, from edit-equipment-id to edit-equipment-id--Ronn-Os05Q0, but my visibility selector is targeting the name attribute, which does not change, so this shouldn't matter.

I have been able to work around this by not using ReplaceCommand to replace the entire select element and instead manipulate the option elements directly:

foreach ($results as $result) {
  $id = $result['id'];
  $response->addCommand(new RemoveCommand('#edit-equipment select option[value="other"] ~ option'));
  $response->addCommand(new AfterCommand('#edit-equipment select option[value="other"]', '<option value="' . $id . '">' . $id . '</option>'));
}

This works, but should not be necessary, as replacing the entire select list should not cause the states of another field to stop working. Doing it this way is also mildly inconvenient because, as far as I can tell, I cannot pass options as a render array (or a subset thereof) to the ajax commands, so I have to write the markup for each option manually.

I get no console errors or anythig

Doesn't work correctly when the form is nested, e.g inline_entity_form module