This fixes #6026

I think blocking all the filtering functionality is a step back, as most of the time when you're changing filters you're going to change a couple of filters at least. With the curent implementation, it's fast to do this, but with the one that's proposed in this PR, this use case of changing multiple filters is really slow because I need to wait until every one of the filters has finished.
This spinner should block only in the filtered contents:

Also, could you add a cursor: wait?

Thanks

Hi @ivan-mr
I'm seeing that we're still with the failing flaky test Meeting issue in the last merged PR. Can we please fast-track this fix? Thanks

Hi @andreslucena and @tramuntanal ,

Seems the last modifications works but maybe could be only that the server is quiet at night.
I comment on this because despite running the meeting test several times I found something very strange.

The previous modification on the reinforcement at the time of selecting the text filter field and the click on the submit button comes because we have located that inside the screen of meetings exists another identical form with the same fields.
It could be the case that certain cases of flaky were due to not correctly filling the appropriate field and then the search results are contradictory (in short that the search is not being performed where the counter test is performed of results).
It could also be that the requests were made in duplicate and that the results of one form (the completed one) were shown first and then the other, and vice versa.
Below are some images of this second form and their comparison by the name attribute that was done above:
The field was previously searched for:
fill_in "filter[search_text]"

Searching the element on screen:

Counting elements with same name:

Searching the duplicate field on "Elements panel":

Reveal panel removing "display: none":

We will continue to work to fix the flaky and find out the reasons why this duplicate form exists and then we will continue the modification of the spinner.
By the way @tramuntanal, the comment on the line about wait_for_ajax, you're right, if not used it should be removed. When we fix the flaky, if not necessary we will remove it.

@ivan-mr it is even possible that both forms are performing 2 separate ajax requests on page load? I found this strange behavior in the proposal's list a couple of days ago..

We should definitively create a separate PR with your change and keep working with the spinner here
We should also analyze why this double filter form

@decidim/core my 2 cents on this double-form thingie: the "second" form is used on mobile. It's actually the same, but duplicated.

The index renders the filters and a "filters_small_view" partial...

... which renders the filters again:

If you check the classes, the filters_small_view has the hide-for-mediumlarge class, while the filters partial is rendered with the show-for-mediumlarge from the index page.

I'm not sure why and I'm not sure if it's needed or if it can be refactored so we just have one single form in the page, but the second copy is used on mobile. It's actually hidden so the tests shouldn't be able to fill those fields. It happens in all components that can be filtered from the public area (meetings, proposals, debates...)

This fixes #6026

I think blocking all the filtering functionality is a step back, as most of the time when you're changing filters you're going to change a couple of filters at least. With the curent implementation, it's fast to do this, but with the one that's proposed in this PR, this use case of changing multiple filters is really slow because I need to wait until every one of the filters has finished.
This spinner should block only in the filtered contents:

Also, could you add a cursor: wait?

Thanks

Now, only affects on the container results:

Now, only affects on the container results:

Awesome 🚀

Could you add a cursor: wait 🙏?

Now, only affects on the container results:

Awesome

Could you add a cursor: wait ?

Hi @andreslucena ,

Do you want the cursor: wait only when the cursor is above the refreshed content or everywhere in the page when there's the ajax calling petition?
Thanks

Now, only affects on the container results:

Awesome
Could you add a cursor: wait ?

Hi @andreslucena ,

Do you want the cursor: wait only when the cursor is above the refreshed content or everywhere in the page when there's the ajax calling petition?
Thanks

Hi @andreslucena . I need to know where you would like to see the cursor: wait .
Thanks!

Now, only affects on the container results:

Awesome
Could you add a cursor: wait ?

Hi @andreslucena ,
Do you want the cursor: wait only when the cursor is above the refreshed content or everywhere in the page when there's the ajax calling petition?
Thanks

Hi @andreslucena . I need to know where you would like to see the cursor: wait .
Thanks!

Finally I applied it above the refreshed content.

Many jobs failed without any feedback. I'm re-runing the meetings and linters workflows to see if they succeed now