On views with AJAX enabled, exposed filter "reset" causes page load

Created on 8 March 2023, over 1 year ago
Updated 14 November 2023, 11 months ago

Problem/Motivation

On a view with exposed filters, reset button, and AJAX enabled, the exposed filters work properly with AJAX (as do exposed sorts, including table heading click-sorting), but when you click the Reset button, there's a page load.

That ^^ on its own feels buggy, but the more problematic effect is: If you're using a view block/embed display, and that view also has a page display (even if you have link_display set to "None"), it doesn't just load the page you're on, it takes you to the view page display URL.

Workaround for "the more problematic effect": Separate the views (moving the page display to its own view or vice versa) -- there's still a page load when you hit "reset" on a block view display, but it keeps you on your current URL.

Note: This issue is "sort of a follow-up" to πŸ› Exposed filter reset redirects user to 404 page on AJAX view when placed as a block Fixed

Steps to reproduce

Reproduced on 9.5.0 and 10.0.5-dev.

  1. Create a view with: a page display, exposed filters, a reset button, and AJAX enabled.
  2. View your view page. At this point, you should see the view results, the exposed filters, and no reset button.
  3. Submit filters. The view results will be filtered without a page load (because AJAX), and now you'll see the reset button.
    • Also works with exposed sorts, and table heading click-sorting.
  4. Click Reset.

Result: There's a page load (and the results are reset).

  1. Create a view with: a page display, a block display, exposed filters, a reset button, and AJAX enabled (I've reproduced it with AJAX enabled on the entire view, and with AJAX only enabled on the block display).
    • I just added a block display to /admin/content, and placed it on a basic page.
  2. Find a place to place your block display (create a node or whatever).
  3. Block layout > Place the view block display somewhere (i.e. on the page you created in step 2).
  4. Go to wherever you placed the view block display (i.e. the page you created in step 2). At this point, you should see the view results, the exposed filters, and no reset button.
  5. Submit filters. The view results will be filtered without a page load (because AJAX), and now you'll see the reset button.
  6. Click Reset.

Result: You're taken to the view page display URL.

Furthermore: If you remove the page display from the view, and redo steps 4-5-6, you'll find that the page reloads in place.

Critical result:
As reported in #8 the issue breaks Core Media Library field widgets modals:
When adding filters to the Media Library view for selecting a media entity in the reference field, the page reloads when clicking "Reset" in the view in the media selection modal.
As a result, all the values entered in the form behind the modal are lost!
See the details here: πŸ› Media library widget reset button redirects user to access denied page. Active

Proposed resolution

The reset button should not cause a page load. Or, if a page load is a necessity, the page should reload in place, you shouldn't be taken from a view's block display to the view's page display.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

πŸ› Bug report
Status

Active

Version

11.0 πŸ”₯

Component
ViewsΒ  β†’

Last updated about 6 hours ago

Created by

πŸ‡ΊπŸ‡ΈUnited States alison

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @alison
  • πŸ‡ΊπŸ‡ΈUnited States alison

    Shoot, I promise I searched around before submitting, but of course I found another issue about this right after I submitted the new one -- so maybe this one I just created is a duplicate?
    πŸ› Views exposed form action incorrect for embedded views' displays with other displays with paths Needs work

    I think both issue descriptions have value, I'm not going to take any action yet (other than to make sure I can reproduce it in 10.0.x) -- but I'll comment with my thoughts on the other one.

  • πŸ‡ΊπŸ‡ΈUnited States alison

    Confirmed / reproduced on Drupal 10.

  • πŸ‡¨πŸ‡¦Canada adriancid Montreal, Canada

    I confirm this problem and there is another situation with this problem if you have AJAX enabled and you have a filter where the user can enter values if an invalid value is entered once you click on the Apply filter button the validation method will show an error. After doing this if you click on the Reset button the page is reloaded and the form is not cleaned and the error validation message is shown again. If you disabled AJAX the Reset button works as expected.

  • πŸ‡ͺπŸ‡ΈSpain rodrigoaguilera Barcelona

    Ignoring the reset button for ajax is actually intentional for some reason I don't undertand

    https://git.drupalcode.org/project/drupal/-/blob/10.0.8/core/modules/vie...

  • πŸ‡ΊπŸ‡ΈUnited States maskedjellybean Portland, OR

    Good find @rodrigoaguilera. I can't think of a reason for this either. I wonder if simply removing that check would solve the problem and if so would the core maintainers accept it.

  • πŸ‡¬πŸ‡§United Kingdom iancawthorne

    @maskedjellybean I've just given it a try, but if the view is expected to return results with no filters applied, when the reset button is clicked, ajax does fire, but the view shows the empty text instead of the expected results.

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    Still an issue. This is especially a problem with the Drupal Media Library Browser for entity reference fields.

    When clicking "Reset" in the modal after filtering the media library view , the page reloads and the whole node form is gone!
    Seting priority to "Major" accordingly.

    A similar issue was reported for contrib entity_browser but it's the same root cause: #3173087: Exposed filter reset button close the modal β†’

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica
  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica
  • πŸ‡ΊπŸ‡ΈUnited States gslexie

    One way to work around this is to override the exposed form template (or maybe form_alter it), replace the clear button entirely with a custom button, and write a Javascript to zero out all form elements and simulate a click of the submit button.

    E.G., this is my script. If you have more complex default values then you may need to customize the script for individual views, but at least it works with AJAX.

        Drupal.behaviors.CustomClear = {};
        Drupal.behaviors.CustomClear.attach = function (context, settings) {
            const buttons = once('custom-clear', '.views-exposed-form input[type=reset]', context);
            buttons.forEach(function(element) {
                const $button = $(element);
                $button.click(function() {
                    const $form = $(this).closest('.views-exposed-form');
                    $form.find('input[type=checkbox]').prop("checked", false);
                    $form.find('select, input[type=text]').each(function() {
                        $(this).val('');
                    });
    
                    $form.find('input[type=submit]').click();
                })
            })
        };
Production build 0.71.5 2024