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.