#JavaScript

Unassigning this so everyone can follow up on this.

We saw this recently but it was combined with another error that prevented the second field from being saved at all:

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /admin/structure/webform/manage/sophie_s_test_webform?ajax_form=1&_wrapper_format=drupal_ajax
StatusText: parsererror
ResponseText: 
Warning:  foreach() argument must be of type array|object, string given in /var/www/html/docroot/core/lib/Drupal/Component/Utility/NestedArray.php on line 330
Warning:  foreach() argument must be of type array|object, string given in /var/www/html/docroot/core/lib/Drupal/Component/Utility/NestedArray.php on line 330

Which we were able to resolve by applying the patch from 🐛 _wrapper_format=drupal_ajax is always added, instead of updated when the param is already available Active .

The autocomplete message still occurs on our sites but we can at least add multiple fields in one pageload now.

There is a simpler approach to this using our already existing useDebounce hook. Hopefully the comments on the MR explain clearly how to implement it!

I can't sign off on this, this is a pure UI MR :)

This should be good for review now.

Moving to core from the ideas queue (which is deprecated).

Moving this to core, agree it should be split up into specific issues.

Most of the discussion here is quite old. I nearly marked this as duplicate of 🌱 [Meta] Make Drupal the first "design-system native" CMS + Unify & simplify render & theme systems Active but rather than doing that I thought it might be better if participants here saw this update and provided feedback on this issue. Marking 'postponed needs more info' in that I'm not sure what concrete suggestions here are or are not covered by that issue at this point.

1.x is no longer supported

Please adjust MR to merge to 2.0.x

Thanks for looking.

If you mean this for item 3, in web/core/misc/autocomplete.js, then what it sounds like is it's removing the element, and then calling destroy on it? It sounds like it shouldn't try to destroy if it just removed it?

detach(context, settings, trigger) {
      if (trigger === 'unload') {
        $(
          once.remove('autocomplete', 'input.form-autocomplete', context),
        ).autocomplete('destroy');
      }
    },

Given how many requests this currently generates to the server, I think it should be a beta blocker. Doubly so because it's a trivial fix on the client side.

1. Investigated and confirmed the issue originates from jQuery UI 1.10+ strict method behavior.
3. Searched Webform module and custom code for any direct autocomplete('destroy') usage.
5. Verified no explicit destroy calls exist — deduced issue happens during Drupal.detachBehaviors().
7. Added data('ui-autocomplete') checks before calling .autocomplete('destroy') in patched logic but it also didn’t work.
9. Explored related Webform behaviors (webformElementStates, webform.form.js, clientside_validation) for improper destroy usage.
11. Validated that validate().destroy() was also unsafe and fixed it using a data('validator') check but it also didn’t work.

Update version to the branch this applies to.

Based on #120 🐛 HTML5 validation is preventing form submit and not fully accessible Needs work , #121 🐛 HTML5 validation is preventing form submit and not fully accessible Needs work , #168 🐛 HTML5 validation is preventing form submit and not fully accessible Needs work , #171 🐛 HTML5 validation is preventing form submit and not fully accessible Needs work , I updated the Proposed Resolution.

RE tests

There are currently several tests for validation error messages in core/modules/system/tests/src/Functional/Form/ValidationTest.php, but they are not failing. I am assuming that the standard browser simulator doesn't support HTML5 validation, and so the problem has been disguised.

To correct this, in the MR I moved some tests from that file to a new FunctionalJavascript file. Those tests will now fail with the current code and pass with the changes in the MR. They check more than simple required fields, and check for multiple error messages.

Still outstanding

The question of whether to make the change globally, or only in core themes.

Gin also suffers from this (and by relation, so dos Drupal CMS?). The Gin maintainers have marked it Won't Fix, stating that it should instead be addressed in core → .

Amending attribution.

Amending attribution.

xjm → credited catch → .

Saving credits per #99.

xjm → credited alexpott → .

xjm → credited effulgentsia → .

xjm → credited star-szr → .

xjm → credited tim.plunkett → .

Crediting as per triage in #3.

Nice research @vinmayiswamy! Sorry for the very long delay in response. It does indeed look like 🐛 AJAX pager doesn't work with exposed filter which has a default value Fixed may have been a duplicate of this issue.

The final step I would take would be to manually test this on Drupal 10.0 and confirm that the bug can be reproduced, and then again Drupal 10.1 (or even a more supported version like 10.5) and confirm the bug is no longer there.

Once that is done, if it shows this issue fixed, we can close this issue as a duplicate.

There is some info in here that is potentially helpful: https://www.drupal.org/project/drupal/issues/2353419 📌 Improve the way how views renders their contextual links Postponed: needs info

It looks like the .contextual element that contains the button and links gets removed on the ajax reload.

I think this is because it's inside the element that is getting replaced.

In the browser inspector, I moved the element outside of the .view element, and then ajax reloads don't remove them!

A potential workaround is to just move them after the initial load, but that feels a little dirty.

Are there any other examples of a component being refreshed with ajax that should have contextual links?

Amending attribution.

Amending attribution.