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 #2820347: Exposed filter reset redirects user to 404 page on AJAX view when placed as a block

Steps to reproduce

Reproduced on 9.5.0 and 10.0.5-dev.

Steps to reproduce the basic issue
  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).

Steps to reproduce "the more problematic effect"
  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: #3376978: Media library widget reset button redirects user to access denied page.

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

Comments

alison created an issue. See original summary.

alison’s picture

alison
she/her
commented
Related issues: +#2844823: Views exposed form action incorrect for embedded views' displays with other displays with paths

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?
#2844823: Views exposed form action incorrect for embedded views' displays with other displays with paths

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.

alison’s picture

alison
she/her
commented
Issue summary: View changes

Confirmed / reproduced on Drupal 10.

adriancid’s picture

adriancid
Primary language Spanish
Location Qc, Canada 🇨🇦
commented

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.

rodrigoaguilera’s picture

rodrigoaguilera
Primary language Spanish
Location Madrid
commented

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...

maskedjellybean’s picture

maskedjellybean
Location Portland, OR
commented

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.

iancawthorne’s picture

iancawthorne commented

@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.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Version: 10.0.x-dev » 11.x-dev
Priority: Normal » Major
Related issues: +#3173087: Exposed filter reset button close the modal

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

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Issue summary: View changes
anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Issue summary: View changes
gslexie’s picture

gslexie commented

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();
            })
        })
    };
anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Related issues: +#3163940: Viewsform has incorrect form submit URL if loaded through ajax, +#3335209: Views exposed filter reset button not working after data export
anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

Just ran into this once again. It's now even worse, with Big Pipe and AJAX enabled, the view doesn't load at all any more, once the "op=X" parameter is present in the URL!

Removing the parameter makes the view re-appear, but it's not cleared.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Title: On views with AJAX enabled, exposed filter "reset" causes page load » On views with AJAX enabled, exposed filter "reset" causes (non-ajax) page load

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

malcomio’s picture

malcomio commented
Related issues: +#3278415: Remove usages of the JavaScript ES6 build step, the build step itself, and associated dev dependencies

Looking at the git history for /core/modules/views/js/ajax_view.js the line mentioned in #5 was done for #3278415: Remove usages of the JavaScript ES6 build step, the build step itself, and associated dev dependencies

See https://git.drupalcode.org/project/drupal/-/commit/04fa72be9332b5c82a80d...