Autocomplete filter stops reset button from firing

I was able to reproduce this on Drupal 9.4.x, standard install.

This also needs an issue summary update, see Write an issue summary for an existing issue for guidance. This is suitable as a first time issue, adding tag.

Created a patch to resolve the issue. Added to patches, Drupal 9.5.x support and 10.0.x support.

Applied patch #13 and it fixes the issue.

RTBC +1

Applied the patch, it works! Thanks @arunkumark .Marking it as RTBC.

Reading the issue summary and seeing the video makes me think we can add an automated test for this using WebdriverTestBase.

Also the issue summary update requested by @quietone has not been done yet.

+++ b/core/modules/views/src/Plugin/views/exposed_form/ExposedFormPluginBase.php
@@ -279,6 +279,9 @@ public function exposedFormAlter(&$form, FormStateInterface $form_state) {
+    if (!$form_state->isValueEmpty('op') && $form_state->getValue('op') == $this->options['reset_button_label']) {
+      $form_state->clearErrors();
+    }
     if ($pager_plugin = $form_state->get('pager_plugin')) {
       $pager_plugin->exposedFormValidate($form, $form_state);
     }

Let's do $form_state->getValue('op') === $this->options['reset_button_label']

Also I would have thought this should come after the pager plugin validations.

So it can clear any errors set there. Or maybe the pager plugin should be an elseif.

@alexpott,
Made changes as per comment #18.
Needs review.

I think actually we can use the FormAPI to help us here... see #3165010: Using the layout builder discard changes button should ignore any input and skip validation for something similar.

I think this might be fixable by changing the reset button render array in \Drupal\views\Plugin\views\exposed_form\ExposedFormPluginBase::exposedFormAlter() to

      $form['actions']['reset'] = [
        '#value' => $this->options['reset_button_label'],
        '#type' => 'submit',
        '#weight' => 10,
        // Reset is not dependent on form input.
        '#limit_validation_errors' => [],
      ];

ie... add:

        // Reset is not dependent on form input.
        '#limit_validation_errors' => [],

Made changes as per #20, needs review. Thanks

I have uploaded the patch and addressed #20

Added patch for upgraded version 10.1.x Made changes according to comment #20

Uploading updated patch as custom commands failed

Here is a really simple test for this, doesn't need javascript, also fails in a normal browser test.

Was hoping that #limit_validation_errors would be enough here, but it is not, but the current solution in exposedFormValidate is also causing problems, so fix needs work.

Updated the IS a bit.

Thanks a lot everyone for raising this issue, it's greatly appreciated.

Thanks a lot @Lendude for updating the IS and patch : we've been having the exact same issue.

The patch from #28 seems to work for us, except for the warning messages popping out after resetting the form, see for example below :

Error message
Warning: Undefined array key "title" in Drupal\views\Plugin\views\filter\FilterPluginBase->acceptExposedInput() (line 1498 of core/modules/views/src/Plugin/views/filter/FilterPluginBase.php).
Drupal\views\Plugin\views\filter\FilterPluginBase->acceptExposedInput(Array) (Line: 183)
Drupal\views\Form\ViewsExposedForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 597)
Drupal\Core\Form\FormBuilder->processForm('views_exposed_form', Array, Object) (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm('\Drupal\views\Form\ViewsExposedForm', Object) (Line: 134)
Drupal\views\Plugin\views\exposed_form\ExposedFormPluginBase->renderExposedForm() (Line: 1253)
Drupal\views\ViewExecutable->build() (Line: 392)
Drupal\views\Plugin\views\display\PathPluginBase->execute() (Line: 196)
Drupal\views\Plugin\views\display\Page->execute() (Line: 1645)
Drupal\views\ViewExecutable->executeDisplay('page_1', Array) (Line: 81)
Drupal\views\Element\View::preRenderViewElement(Array)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was %s. See https://www.drupal.org/node/2966725', 'exception', 'Drupal\Core\Render\Element\RenderCallbackInterface') (Line: 858)
Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array) (Line: 421)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 240)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 238)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 239)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 128)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 186)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

See screenshot below :

 

Which seems to also be part of the reason the tests could have failed at #28.

If we could perhaps prevent these warning error messages, this patch could potentially become exploitable.

Therefore, please find attached to this comment an updated patch which prevents warning messages and resets the exposed filters values:
File attached as: 2833223-33-core-autocomplete-filter-stops-reset-button-from-firing-warning-messages.patch
Interdiff: interdiff_28-33.txt

I've tested this with required and grouped filters as well and it seemed to work, but this definitely needs help reviewing and testing.

Honestly, I haven't spent more time than this, looking into finding a more appropriate solution, as suggested by @Lendude, or in the IS, trying to "Skip validation when using the reset button". So I really have no clue whether this is the right way to fix this.
I've only really tried fixing the symptoms instead of finding the root of the issue.

Therefore, we would greatly appreciate some help reviewing and testing this updated patch and more particularly whether anyone would see potential regressions or side effects introduced by the change in this patch.

Thanks in advance for your feedback and comments.

It is recommended to use MRs as patches are being phased out and DrupalCi is less supported these days.

But #33 appears to have test failures.

Did not test or review.

+        options:
+          submit_button: Apply
+          reset_button: true
+          reset_button_label: Reset
+          exposed_sorts_label: 'Sort by'
+          expose_sort_order: true
+          sort_asc_label: Asc
+          sort_desc_label: Desc

If this change updates a view config we will need an upgrade path for existing sites.