On a page with multiple Views exposed Ajax enabled forms, multiple throbbers appear on submit

Interesting, this sounds indeed like a total bug in views.

Indeed an issue . Good catch vaibhavjain.

SwapS

I had the samme issue when inserting the same view with an exposed form multiple times.
It seems to be related to the selector used to add the javascript. It uses the id of the exposed form and this id is the same for each instance.
Adding the surrounding forms (unique) id as a context to the jquery selector fixes the problem.

Notice, that my patch in #6 don't work with exposed forms inserted as blocks outside the view dom.

We will need a fix that either :

- only use the context if the exposed form is not placed with a block
- change the form id to a class and update the selector in the javascript to use this

We can make selectors contextual by exposing the block ids via block alter via drupalSettings & using the same in ajax_views.js . Adding a patch for 8.3.x here.

Apologies, Patch #1 uploaded accidentally. Was meant for facets module.

Reroll the patch for 8.4.0

Setting to needs review so that the testbot can pick this patch up.

Thanks for working on this issue! There are a couple of things we need in order commit this fix:

1. I'm wondering if there's a particular reason we have to attach this build information in hook_block_view_alter(), rather than in the block class itself in /core/modules/views/src/Plugin/Block/ViewsExposedFilterBlock.php? Tagging for subsystem maintainer review for feedback on the solution.
2. We need to add an automated test for this bug that fails without the fix, and passes when combined with the fix. We can probably extend core/modules/views/tests/src/FunctionalJavascript/ExposedFilterAJAXTest.php for that.
3. It looks like this patch only has the ES5 javascript file. Instead of changing /core/modules/views/js/ajax_view.js, we should change /core/modules/views/js/ajax_view.es6.js, and ajax_view.js should be auto-generated from it. See the change record about ES6 for more information. The JS will probably also need a few changes to comply with the AirBnB coding standards. See #2912962: Step 1 JS codestyle: [meta] Fix JS coding standards in core for more information on checking the ES6 file against the standard.

Thanks!

I agree with #16.1, this should be added to \Drupal\views\Plugin\Block\ViewsExposedFilterBlock::build()

I have tested this on a page with multiple exposed filters in different parts of the DOM.

I believe its a relatively simple fix and just an oversight TBH.

This seems like related.

consolidating issues under the JavaScript tag

Setting to review as patch in #22 doesn't apply for the feedback on #16

Quick reroll so the patch applies on 9.2

On Drupal 8.9.x, only security issues are fixed.

Rerolled the patch to apply to 9.3

Patch updated for 9.4 .

I wonder how we should test this though. Ideally we should be able to detect multiple requests in a functional JS test, but can it be even done in Drupal's testing framework?

Whoops, wrong patch. This one follows Drupal's js practices and building process.

Let's try again.

Alright, this is my attempt at testing for this issue. I'm not sure if that's the best way of doing that, but it's something.

And again a patch issue -_- . Here is the correct one.

And here is the complete solution.

I think the previous error was caused by my IDE adding EOL at the end of the file, where it shouldn't be. Let's hope we will finally get it working.

Update the patch #6 by @thelmer to work with version 7.x-3.24.

This issue is for Drupal 9 core views module. If you would like to patch Views module for Drupal 7, please create an issue in the Views issues queue here: https://www.drupal.org/project/views

Reverting version.

patch #41 works for me on Drupal 9.3.13

Also happy with the #41 patch as it fixes my double throbber trouble.

patch #41 is also working for me on 9.4.5. I was wondering why my search was getting progressively slower and the throbber wasn't disappearing.

NOT WORKING (patch #41) on 9.4

Is there is a patch but it's not addressing the issue, the status to set is needs work :)

@kazah
Me, @rondog469 and tests confirmed that this patch works on Drupal 9.4. Could you please describe the steps you followed to get your result? Could anyone else chime in?

After applying patch #41 ajax throbber not disappear the same as in comment #48

I am using better exposed filters module with ajax enabled option.
Still have two ajax throbbers, after click apply first throbber dissapear the second still exist.

Also I found that barrio theme use button as submit element not input.

I am using bs5 theme and submit button is an input. The patch looks like it takes into account if its a button or input

Ok, it works in bartik theme.
But for some reason it doesn't work it barrio theme...

@kazah
Does barrio's button have type="submit" attribute?

Thank you all! Now it works.

Barrio theme rewrites ajax_view.js

I delete these lines in bootstrap_barrio.info.yml

  views/views.ajax:
    - bootstrap_barrio/views.ajax

Good to hear that you managed to solve it. It means that barrio needs to port this change to its ajax_views.js to have it fixed. I'm switching back to the Needs review status. I hope we can get RTBC soon.

I also made a patch for Drupal 10.

Forgot to run phpcs, so here is the patch with fixed styling issues.

I see what went wrong with D10 patch. Attempt at fixing it.

This could use an issue summary. Started it but someone familiar with the issue should fill in

I tested the patch in #65 and it applies and works fine with Drupal 10.2.5. My use case is that I want different parts of the same exposed Ajax form in 2 areas of the page. This works as expected, no log errors, no console errors, or Ajax errors.

Something that baffles me is the form ids are duplicated for each implementation of the exposed form. There are a number of issues open for that, a few in the "Related" and "Referenced by" section on this page. I always understood that duplicate form ids were not good for accessibility and could cause unexpected issues so just wanted to flag that with this patch.

This patch was modified to work with Drupal 10.3.6.

It's been a while this issue is opened and the patches (re-rolls) apply and work succesfully, can this be merged into core now or, are there any other pressing issues stopping this patch merge?

Patch #71 works fine for me btw!

I've updated the issue summary, and created a merge request based on the patch from #71 as the patches have been deprecated.

Setting back to needs work due to the failing coding standards issues picked up in the pipeline.

Amending attribution.

I fixed code style problems but now some unit test is failing.

I fixed the failing tests.
There are still some tests failing on PHP 8.5, but I see the same failurs on the 11.2.x branch:
https://git.drupalcode.org/project/drupal/-/pipelines/614551

So I think those are not related tot his issue.

Seems this may need a manual rebase.

I merged the latest main and fixed a deprecation.

Ran the TEST-ONLY test:

https://git.drupalcode.org/issue/drupal-2876197/-/jobs/8938220

There is one test failure relating to the assertion at line 121 of the test. Test coverage LGTM.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. 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.