Reset button does not use AJAX

+++ b/src/Plugin/views/exposed_form/BetterExposedFilters.php
@@ -838,10 +778,21 @@ class BetterExposedFilters extends InputRequired {
+    if (isset($form['actions']['reset'])) {

@@ -933,4 +856,229 @@ class BetterExposedFilters extends InputRequired {
+            $handler->value = $handler->options['value'];

Is there any particular reason this code $handler->value = $handler->options['value']; is implemented here? I can't seem to see the benefit of having it. I went ahead and commented it and the reset button still working fine.

Asking because its presence is causing a php warning when a custom handler doesn't have a value option.

I do think most of this is a core issue -- I can't speak to the auto-submit use cases -- but (*after* submitting a new issue, of course!) I see this existing issue:
🐛 Views exposed form action incorrect for embedded views' displays with other displays with paths Needs work

And now my new issue, which maybe should be marked as a duplicate, but I'll share anyway, in case our different explanations are helpful to anyone:
🐛 On views with AJAX enabled, exposed filter "reset" causes page load Active

@er.garg.karan Thanks for the patch #74.
But Reset button still do not work for the next conditions:
Exposed form in block: Yes.
Use AJAX: Yes
In this scenario when click reset button nothing happens.

#74 patch is working for me with better exposed filters, auto-submit, ajax, and a modified input--submit.html.twig file.

I am not sure if this is a related issue. I am using views_filters_populate to combine multiple fields into one filter and ajax reset button does not clear the results when view is being filtered on this populate combined filter field.
I have applied the https://www.drupal.org/project/better_exposed_filters/issues/2996297#com... 🐛 Reset button does not use AJAX Needs work patch and it does not fix the issue I am having.
Testing in drupal 9 and drupal 10
Will appreciate any guidance on fixing this issue.

In my case, patch #74 causes reset button to cleanup filters, but not reload results. Pressing reset button a second time alse results are AJAX reloaded.

This error still exists in 6.0.x. The patches doesn't apply though.

stBorchert → changed the visibility of the branch 6.0.x to hidden.

stBorchert → changed the visibility of the branch 8.x-5.x to hidden.

Created a merge request based on the previous patches and that works for us.

Tested #88 on D10.2.6 and it fails. Checked out the MR and only difference I can see is that the "){" of the construct method are on the same line in the source code and on a new line in the MR. When applied, the error is thrown as it could not apply and the $request argument doesnt get put in the argument list of the construct() method.
Im not sure if I can make edits to MRs here (they are a bit new for me in Drupal issues) otherwise I would suggest an edit. Hope this helps

Here is a patch for BEF 6.0.5 specifically, using the patch from #88. This one accounts for the difference between versions 6.0.5 and 6.0.x with the construct method having the "){" on the same line in 6.0.5 which prevented #88 from applying.
I wasnt sure how to create a MR against a tag (Im probably missing something super simple) but if its possible, please message me and Ill update this to an MR.

Okay, I have been testing both the MR against 6.0.x and the latest patch file (thanks @peachez) against 6.05 and they look good. I have tested both BEF exposed filters in their default UI and altered to use others, like checkboxes and radio buttons. The behaviour of using AJAX to reset the form seems consistent and performant.

We have had several good iterations now and I believe this is ready for RTBC.

Can the MR be updated to make sure tests and phpcs run fine.

smustgrave → closed merge request !75

And there were a few phpcs errors that needed to be fixed.

Finally! Congratulations!

Automatically closed - issue fixed for 2 weeks with no activity.

I expected a credit for my patch contribution in #74.

We have found this to be not working with facets. Didn't test it with other exposed filters.

Basically, the Clear Filters will on first click reload the results via AJAX but keeping the same parameters - so, results are kept unchanged even if the form is cleared - and on second click will finally show all content, unfiltered.

It is important to note, first, that Drupal core itself does skip the AJAX reload for reset buttons and states that "many things break during the form reset phase if using AJAX" (ajax_view.js).

    // Exclude the reset buttons so no AJAX behaviors are bound. Many things
    // break during the form reset phase if using AJAX.
    const $exposedFormInput = $(
      'input[type=submit], button[type=submit], input[type=image]',
      this.$exposed_form,
    ).not('[data-drupal-selector=edit-reset]');

This code in core is basically skept because of this line that alters the ID and the data-drupal-selector for the reset button, making the .not('[data-drupal-selector=edit-reset]') condition fail.

$form['actions']['reset']['#id'] = Html::getUniqueId('edit-reset-' . $this->view->storage->id());

So, if you need - as we do - to revert back to the no-AJAX reset button, you can just comment this line as a workaround.

I think this change needs to be re-reviewed. Should I create a new one or do maintainers prefer to re-open this?

Would open a new one but this has been out for a while so can’t just take it back