The exposed form reset button does not work for the filters. It just redirects to the homepage. If I use firebug and look at the form I see:
<form accept-charset="UTF-8" id="views-exposed-form-careers-block" method="get" action="/" class="views-processed">

Obviously it is the action that is incorrect and I do not know why it is doing that. Here is the page it is causing problems:

http://firstwind.silvereastdesign.com/about/careers

Comments

dawehner’s picture

Category: support » bug
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

Can you please try out the beta release? There are so many things fixed it's impossible to count/remember

esmerel’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)
brandy.brown’s picture

Version: 7.x-3.0-alpha1 » 7.x-3.0-rc3
Status: Closed (cannot reproduce) » Active

I am using Views 3 and am having the same problem. I have multiple exposed filters on an AJAX enabled view. I am also using quicktabs, but I don't think that's an issue as I have tested this problem with views that are not using quicktabs.

vlooivlerke’s picture

Same problem here with exposed form filters and Ajax

Works with Ajax and exposed forms if filters are not exposed.

brandy.brown’s picture

vlooivlerke are you using the Better Exposed Filters module?

vlooivlerke’s picture

no, Let me have a look at it thanks.

I am building a view and will post link for all to see soon.

greggles’s picture

Status: Active » Postponed (maintainer needs more info)
Todd Young’s picture

I am having the same issue, and I am not using QuickTabs. To work around the problem I used jQuery to set the onlick of the reset button to the same page name and added '?name_op=contains' after it (the default operator for my 'name' field) - this dumps the form values.

vlooivlerke’s picture

Here is a link to my site with an reset button
http://wikivillage.co.za

It works on Ajax paging
HS and autocomplete fields
and exposed sort filter and pager

To test, dont make any search just clcik rest (more than once)
Notice how the comapact forms labels move from within the search fields to top labels.
When you see this the form is broken and "HS and Autocomplete dont work any more"
To fix, page one page and all returns to normal

I needed this to go live on my production site so I have hidden the "JS errors of HS" when reset button is clicked via css:hidden. Not a good solution
Any ideas?
o yes, it is on a local server in South Africa so the website will take long to load (3rd word problems, not drupal)

dawehner’s picture

I'm a bit confused because this site works fine for me. Maybe you have already fixed this in the meantime?

What happens if you remove HS? Maybe you should check that out and then report an issue against HS.
If we should develop a proper fix we need a good way to reproduce your issue.

vlooivlerke’s picture

The issue is with "views-processed"

If you use ajax views and you click on search or reset buttons (more than once) the view-processed css change, causing form elements to break in style and function

http://drupal.org/node/1246672

thoughtcat’s picture

I get the same (or similar) problem. I've created a view with a page and block display. Both have "reset" buttons set in "exposed form style", but when you click "reset" in the block, it takes you to the page view instead of resetting the block view. The reset button works OK in the page view.

rlangille’s picture

I have experience the same issue, and tested it on a vanilla install of Drupal with views. To recreated it, simply create a view that has a block display, exposed a few basic items such as published and promoted status as filters, enable ajax, and set the block to display on any page except the home page. When the reset button is clicked, the user is redirected to the home page instead of resetting the filters.

stongo’s picture

In D6 this problem was solved by the method $view->override_path()
This method no longer exists for D7 'view' class
I am also having this issue and unsure how to fix it.

brandy.brown’s picture

as an update: the reset works as expected when used with exposed filters on a gmap or calendar view ... just not on a regular unformatted list or grid, etc.

jh81’s picture

Version: 7.x-3.0-rc3 » 7.x-3.3
Component: User interface » Code

Same problem here when using quicktabs. I really need a fix for this as it makes the quicktabs pretty useless because it takes you back to the page when you reset the filters and you loose the quicktab.

alx_benjamin’s picture

I use quicktabs, exposed form in the block and panels. Quicktabs are in one column, block with the form in another column.
Form uses AJAX.

Submit button works as it should updating results in the quicktabs. However reset button redirects to the view page.

I've temporarily fixed reset button with this jQuery code:

$('#reset-button').click(function(){
$('#views-exposed-form').each(function(){
this.reset();
});
$('#submit-button').click();

return false;
});

This clears/resets content of every field in the form and triggers 'click' action on submit button.

Hope this was helpful.

jh81’s picture

For #17, how/where are you adding the jQuery code for the fix?

erin814’s picture

Having the same issue here. I have exposed filters and a grid style layout for views. When I hit reset, it works in the admin view but on the live view, it redirects to the homepage.

esmerel’s picture

Status: Postponed (maintainer needs more info) » Active
osopolar’s picture

Somehow the inherit from page does not work for the reset button, but for the form elements it's working. As a workaround I use this code in a custom module:

/**
 * Implements hook_form_alter().
 */
function custom_form_views_exposed_form_alter(&$form, &$form_state) {
  // Workaround, because on a Ajax-Request the url of the current panel page gets lost
  // and "/" is used instead.
  if (isset($form_state['view']->current_display) && 'panel_pane_1' == $form_state['view']->current_display && $form['#action'] = '/') {
    // Fix action URL.
    $form['#action'] = '/' . $_GET['q'];
  }
}
osopolar’s picture

Now some more info about I found debugging the problem:

The exposed form action is build in view.module:
$form['#action'] = url($view->display_handler->get_url());

In my case $view->display_handler->get_url() means views_content_plugin_display_panel_pane::get_url() and because I set inherit_panels_path for my panel pane to true views_content_plugin_display_panel_pane::get_path() gets called. override_path is not set, so parent::get_path() will be called which should be views_plugin_display::get_path(). But neither $this->has_path() nor $this->get_link_display() is set.

The question is, how to get the url/path into the view and back to the $form['#action']?

Anonymous’s picture

I had the same issue (on blocks with exposed filters) I followed the code provided by #17 and changed it to fit my forms.
this is my code inside my js file.

$(document).delegate('#edit-reset','click',function(event)
  {
    event.preventDefault();
    $('form').each(function(){
    $('form select option').removeAttr('selected');
    this.reset();
    });
   $('.views-submit-button .form-submit').click();
    return false;
  });

It will also take care of the selected items in dropdown lists,etc. I'm sure there is room for improvement but i just wanted to share how i solved the issue, enjoy!.

corvus_ch’s picture

[#1881884: Reset does not work broken on pages with multiple displays.] contains an example on how this can be reproduced. In the situation there, the ajax behavior does not get attached to the reset button unless you refresh the page.

Comment #21 does fix this problem, but i consider this more a hack than a real solution.

warmth’s picture

I'm having the same issue, subscribing...

mstef’s picture

Reset not working for me with AJAX views. I get an endless redirect when clicked.

damiankloip’s picture

@mstef: have you upgraded your version of views, this shoudl already be fixed, and not the same as this issue. #1807916: Reset button on exposed filters causes a redirect loop

mstef’s picture

ah - i thought i had the latest dev in, so I didn't see that issue. thanks damian.

dawehner’s picture

So is it just me, or can we mark this issue as fixed?

damiankloip’s picture

Status: Active » Fixed

Well the patch is committed. Not sure there is any value in talking about this more. If people haven't updated views, that's their problem :) let's close it.

iLLin’s picture

Status: Fixed » Active

This has not been fixed in the latest DEV. #22 has the start of troubleshooting as the AJAX block still inherits the page displays URL. There is no real solution in this thread only work arounds. @damiankloip, not sure which patch your talking about?

I used code from #21 and that caused a redirect loop like @mstef encountered but updating to the latest views fixes the redirect issue. The original problem on this thread still exists.

iLLin’s picture

Title: Exposed Form Reset button does not work » Exposed Form Reset button Inherits the page display URL when using as a block and AJAX
Version: 7.x-3.3 » 7.x-3.x-dev
GBain22’s picture

I am using Views 7.x-3.5 and Views Better Exposed Filters 7.x-3.0-beta3

The issue is obviously that a block of content with an exposed view MUST use Ajax as their is no URL for it to append an arguments to. I have tried using the Jquery code from post #23 but this just gave me an error saying "Uncaught TypeError: Property '$' of object [object Object] is not a function" so I cannot use it.

Has anyone else resolved this?

iLLin’s picture

You can use the same approach as #21. Just change it to your display name.

Anonymous’s picture

That sounds as a conflict problem are you adding the jquery as drupal standards?

(function ($) {

  // Use jQuery with the shortcut:

}(jQuery));

more info https://drupal.org/node/171213

bcobin’s picture

Same problem here - I've had to disable AJAX for the view, which I don't want to do. Reset on exposed filters sends user to the front page with a query string like ?tid=92&tid_1=All&op=Reset.

With AJAX disabled, things work as expected. There seems to be two issues under discussion here: the redirect loop issue (which I'm not experiencing) and the redirection to the front page, which is my current problem.

Using latest versions of everything, including Views 7.x-3.x-dev - has there been any recommended solution here? Any guidance much appreciated... thanks!

Anonymous’s picture

Are you using the jQuery update module? because I'm not and my solution #23 is just working fine.

bcobin’s picture

Thank you, @kentoro - I am using jQuery Update and (as I'm developing the site) the Twitter Bootstrap theme. Inserting your code in the theme .js file does, indeed, work a treat!

Thank you very much - I suppose I'll leave this open for now insofar as it seems like more of a workaround than a solution... but I'll take it!

Thanks again - you've been a huge help!

Anonymous’s picture

My pleasure :)

Anonymous’s picture

Priority: Normal » Minor

Changing the priority to minor since there is a workaround.

bcobin’s picture

One more thing (unfortunately):

I have two exposed forms on the page - one for each of the major options. Reset resets both, which rather defeats the purpose.

Is there any way around this? Thanks again for any guidance...

cm1se7en’s picture

Thanks osopolar #21
I'm OK with $form['#action'] = current_path();

Anonymous’s picture

@bcobin
Hey,
It's true that my solution #23 was made for only one form in the page BUT your forms should have a class or id with it, since I was using the jQuery selectors you could specify that as ('#form1-#edit-reset') is clicked, then reset, then the same for the other one.
insted of the more general ('#edit-reset') Hope it helps.

PTL’s picture

Thank you for your code from #23. I can solve it now.

bcobin’s picture

@kentoro

Yes - a belated thank you for your code! For unrelated reasons, I've settled on a slightly different mechanism that requires only a single exposed form on the page, so #41 is no longer an issue for me.

It's all working great and the site will be super-cool - I'll post back here when it's up, but for now, thanks so much for taking the time and being so quick on the uptake... I am grateful!

tsonye’s picture

I know this thread is quite old now but I am having the same 'reset-button-homepage-redirect' issue and I can't seem to apply the workarounds mentioned in this thread.

Specifically, can someone explain where I need to write the .js code in #23

Any help will be much appreciated!

Anonymous’s picture

Hi, you should place it inside your theme's custom js file.
see no:38 by becobin, when he puts the code inside his theme's js it works as it should

jh81’s picture

The code in #23 does not work for me. I am using the current version of Views and I have a large number of views all of which use Ajax and some that use QuickTabs. All of my views have the same issue where clicking the reset filter button either redirects you to the page or redirects you to the site home page. Does anybody know when this is going to be fixed? This thread is over 2 years old and I have had this issue for about the same amount of time. Its very frustrating that I cannot provide a reset filter button to my users.

boregar’s picture

The code in #23 worked fine for me (Drupal 7.24 / Views 3.7). Thanks kentoro!
@jh81: for testing purpose, you can try to create a html block with the following code and add it to the content region of your theme.

<script>
(function ($) {

  $(document).delegate('#edit-reset','click',function(event) {
    event.preventDefault();
    $('form').each(function() {
      $('form select option').removeAttr('selected');
      this.reset();
    });
    $('.views-submit-button .form-submit').click();
    return false;
  });

}(jQuery));
</script>
jh81’s picture

@hillmore, I was able to get this working following your directions. Thanks!

pixel6’s picture

Issue summary: View changes

The code in #23 worked fine for me too! Thanks.

jamesdixon’s picture

Code #23 was close to working for me, but was not reseting text fields. The following snippet got the reset button working for me:

(function ($) {
  $(document).delegate('.views-reset-button .form-submit','click',function(event) {
    event.preventDefault();
    $('form').each(function() {
      $('form select option').removeAttr('selected');
      $('form input[type=text]').attr('value', '');
      this.reset();
    }); 
    $('.views-submit-button .form-submit').click();
    return false;
  }); 
}(jQuery));
stongo’s picture

All this jquery is good, but it still doesn't address the bug. What happens if a client has a javascript disabled?
This used to be fixable in Drupal 6 (see comment 14) properly with php, and isn't anymore in D7

PhilY’s picture

Hi,

#52 doesn't seem to work with Better Exposed Filters but only on regular Views filters

PhilY’s picture

Here is what I did to have it working with both regular Views exposed filters and BEF filters: the filters need to be exposed in their own block, which is not possible with Ajax blocks except by using the Views Block Exposed Filter Blocks module.

So, here is my process (Views 7.x-3.7, BEF 7.x-3.0-beta4):

  1. the views main output is a block
  2. view's Ajax is set to 'on' to have exposed filters being displayed
  3. exposed filters settings: autosubmit + reset button + hidden submit button
  4. this way, resetting is messy (leads to homepage)
  5. thanks to 'Views Block Exposed Filter Blocks' module, expose the view's filters in a block
  6. place the exposed filters' block so it can be shown with the view
  7. et voilà: reset button works, even on multilingual site

Hope this will help some readers ;-)

PS: no need of module hack or js/jQuery script

i.bajrai’s picture

I think everyone here is having an issue when the view is in a block.
However I have this issue but in a slightly different way.
My module is injecting the view via a custom menu callback, therefore in the view there is no page URL created.
I have solved it by having the view use AJAX.
However when the exposed form uses autosubmit if you press enter while the throbber is spinning it will post to the form action again.
Perhaps views need to read the page URL if a page url is not provided?

phoang’s picture

For anyone use the #1109980-21: Exposed Form Reset button Inherits the page display URL when using as a block and AJAX solution, I used this as specific form and it works for me.

/**
 * Implements hook_form_alter().
 */
function HOOK_form_views_exposed_form_alter(&$form, &$form_state, $form_id) {
  if ($form['#id'] == 'your-form-id-block') {
    $form['#action'] = array();
  }
}
Anonymous’s picture

Status: Active » Needs review

@jamesdixon nice you extended it to fit your needs, the problem there is that there are many input elements in HTML5 that are not of type text, such as url, telephone etc. I was going to extend this when i saw the comment on #55 which seems to be at a glance a better option.
could anyone test the solution on #55 further?

kunkunkun’s picture

It also happens when using exposed filter in a view content pane.

Anybody’s picture

Here you can find a solution that replaces the default reset functionality by an AJAX version. It doesn't have the problems described above. http://julian.pustkuchen.com/node/659

I hope it helps some of you as a workaround.

jennypanighetti’s picture

The code in #52 was the only one that worked for me. Thank you, combination of commenters!!

mxlav’s picture

#60 worked nicely thanks @Anybody!

jelo’s picture

#60 worked nicely for me as well. Thanks!

jelo’s picture

I just noticed that the patch in #60 does not work if the view has exposed filters and one of the filters has the option to "Remember last selection" ticked. It won't reset that field to ANY then...

darvanen’s picture

#55 did the trick for me, thanks @PhilY!

franksj’s picture

We went with #52 but then we got complaints that the URL was too long and when we hit reset, we want to have just the clean url. So, for instance, http://drupalissoawesome.org/viewmaster instead of http://drupalissoawesome.org/viewmaster?title=&field_single_term_tid=&fi....

Instead of looping through the forms and unselecting everything, then calling the Search button, I started playing around with simply taking the user back to where they started.
Like so:

(function ($) {
    $(document).delegate('.views-reset-button .form-submit', 'click', function (event) {
      window.location = window.location.href.split('?')[0];
      return false;
    });
}(jQuery));

This way, when we click Reset, it doesn't bother with any resubmitting, clearing options, or anything. It behaves as though the user clicked the link to the page/view again.

Maybe not a one size fits all, but it definitely fit what we were trying to do.

darvanen’s picture

So simple. Thanks franksj, worked for me (on another site where I couldn't use #55).

phileas75’s picture

#52 works for me ! Thx

mobius_time’s picture

Thank you, PhilY, your solution at #55 using that module worked for me!

dgtlmoon’s picture

Status: Needs review » Needs work

#55 worked for me, but I'm unsure if this is a fix or just a workaround

darvanen’s picture

It's a workaround, but, to be honest, with D8 released we may not be that likely to get a fix for this in D7.

milos.kroulik’s picture

Workaround from #55 works also with Views content panes. But it would be great, if there would be a way to change URL.

Alina Basarabeanu’s picture

Using a view without a url and BEF the only solution was #66. Thanks

capfive’s picture

Great fix with the javascript! Thanks this really helped! (#66)

Alauddin’s picture

#66 works for me as well, but ran into issue where it gets applied to ALL my views with BEF exposed filter.

I only wanted to apply this to non-ajax view filters, so added 'noajax-filter-reset' class to views that needed this reset.

hope it helps others.

      // Start of views reset https://www.drupal.org/node/1109980#comment-10421063
         $(document).delegate('.noajax-filter-reset .form-submit.my-views-filter-reset', 'click', function (event) {
         window.location = window.location.href.split('?')[0];
         return false;
         });
       // end of views reset
weynhamz’s picture

Get bitten by the same problem here, exposed form with AJAX enabled will be redirect to homepage, has to disable AJAX. It has been almost half decade, hasn't there be a real fix instead of this js workaround?

scotwith1t’s picture

Also implemented #66 for its simplicity. Thanks!

nmalinoski’s picture

URL inheritance issue seems to be occurring for me (view block, AJAX on, input required), but in my case, the URL it inherits is an admin URL, so users end up with an Access Denied message--from clicking the Reset button! It gets even better when you disable JavaScript--the Apply button sends users to the same access-denied admin page.

Using Views Block Exposed Filter Blocks alleviates the issue, but this is something that should work out of the box (so to speak).

amogiz’s picture

#66 works perfect for me.
Great thanx !!!!!!!

amogiz’s picture

#66 works perfect for me.
Great thanx !!!!!!!

acrosman’s picture

I agree with @nmalinoski that this should work correctly by default. The JS from #66 worked in our use case, but it's hardly the best possible solution.

diamondsea’s picture

I got around this in #2781117: Configurable timeouts on auto-submit, ignore Enter key option by using AJAX with the CTools patch on that ticket, using the "Ignore Enter Key" option to prevent the ENTER key from causing the action tag to fire. You'll still have the wrong-action issue if JS isn't enabled, but it works otherwise.

If it works for you, please Review/RTBC it and then I can submit the 3-line Views patch (described in the description).

neilsavage’s picture

#23 worked for me when selecting exposed filters with dropdowns. I had a search form enabled as well so I added a line to clear that as well:

$(document).delegate('#edit-reset','click',function(event)
    {
    event.preventDefault();
      $('form').each(function(){
      $('form select option').removeAttr('selected');
      $('form input').attr('value', ''); 
      this.reset();
      });
      $('.views-submit-button .form-submit').click();
      return false;
    });
jasonflaherty’s picture

I didn't see this post in the comments, but this module helped my quicktab / views block exposed filters issue: https://julian.pustkuchen.com/node/659

Thanks to the author!

andriarijaona’s picture

Title: Exposed Form Reset button Inherits the page display URL when using as a block and AJAX » instagram integration
Issue tags: -exposed filter form, -block in views, -ajax views +Social Timeline - instagram integration

Social Timeline - Can you provide these files please for instagram integration:
Set Instagram Credentials
Copy the Client ID into the files in the libraries folder: instagram_auth/instagram.php and instagram_auth/instagram_hash.php4

joelpittet’s picture

Title: instagram integration » Exposed Form Reset button Inherits the page display URL when using as a block and AJAX
Issue tags: -Social Timeline - instagram integration

Hmm not sure what that change of title was all about...

maxplus’s picture

Hi,
working with views content panes and views filters with ajax: #66 helped me out, thanks!

alibenski’s picture

Hello,

jQuery script in #52 worked for me - using BEF, view selective filter, and dependent filter with AJAX. Thank you.
Also, I used JS Injector module since this code was messing up a certain functionality of the reset button of a Views block without a page display in another part of my website. Just wanted to share this information in case you find yourself on the same boat.

e.ryan.schmidt@gmail.com’s picture

#52 worked great! Thank you!

arunkumark’s picture

+1
The patch #52 working perfectly to reset exposed form. Am using exposed form in my CTools popup, it works as expected.

Aporie’s picture

Thanks #60 worked for me.

ogomez78’s picture

I'm concerned that there may be multiple ajax views exposed forms on the same page so I wanted to limit the scope of the reset event to only the form the button clicked is in. Also if the Better Exposed Filter module is in use, there may be checkboxes, and radios that need to be cleared as well, so that would need to be added to this code below.

I added this code below to my theme's scripts.js file:

// Fix ajax reset button

$('.views-reset-button .form-submit').click(function (e) {
  e.preventDefault();
  $(this).closest('.views-reset-button').siblings('.views-exposed-widget').find('select option').removeAttr('selected');
  $(this).closest('.views-reset-button').siblings('.views-exposed-widget').find('input[type=text]').attr('value', ''); 
  $(this).closest('.views-reset-button').siblings('.views-submit-button').find('input').trigger('click');
});
markabur’s picture

Thanks, using #66

axion’s picture

In my case I was dealing with a block ajax view that had exposed filters and selection history stored in a session for both anonymous and authenticated users. Tried all of the above and more... The only thing that resolved this for me was a simple:

$('.your-view-selector .view-filters form').attr('action', window.location.pathname); (don't forget the Drupal.behaviors wrapper)

P.S. This will successfully reset your filters, but will reload the same page instead of redirecting to front page

axion’s picture

I was dealing with an ajax block auto-submitting view, that memorizes selection of multiple exposed filers for bot authenticated and anonymous users.
None of the above has helped. What did resolve this for me was a simple:
$('.your-view-selector .view-filters form').attr('action', window.location.pathname);
(Don't forget the "Drupal.behaviors" wrapper)

This is by no means a proper fix. It will reload your current page when you reset the filters. But resetting will work and you won't get redirected to the front page.

dalemoore’s picture

Confirmed #55 works without needing to fool with any extra JavaScript additions. It's also nice to be able to position the filters where I want, now that both the filters and the view are separate blocks!

rpataca’s picture

#57 worked great. Worked on Drupal 8 !

Thanks @phoang

osab’s picture

using #66, works perfectly! Views version: 7.x-3.20

bmsomega’s picture

#52 works like a charm for me! Thanks @jamesdixon!

Anonymous’s picture

#66 works still. To me this looks like the most simple way around this problem. Thanks!

GuyManDude’s picture

I tried all the potential fixes offered in this thread and I could still not get the previous results AND searchbox contents cleared with the Reset button. I ended up installing the Views Better Exposed Filters module and using it in conjunction with the following script added to either a Global Text Area (within the View you're using), or in a basic Block added to the Content region.

Hopefully this save someone a lot more time than it took me to get it all working.

<script>
(function ($) {
  $(document).delegate('.views-reset-button .form-submit','click',function(event) {
    event.preventDefault();
    $('form').each(function() {
      $('form select option').removeAttr('selected');
      $('form input[type=text]').attr('value', '');
      this.reset();
    }); 
    $('.views-submit-button .form-submit').click();
    return false;
  }); 
}(jQuery));
</script>
someshver’s picture

#23 solved my problem. Thanks

robbdavis’s picture

@GuyManDude, that's @JamesDixon's fix from #52. Trying to pass it as your own? Sheesh.

Thanks @JamesDixon you Drupal rockstar; I plugged in your code and... boom... working reset button.

jamesdixon’s picture

Hahaha @robbdavis thanks for brightening my day bud! Glad I could help you out :)

Shrutidkadam’s picture

#52 code works for me, but search value remains in search field but output gets updated with empty value. Can someone help me on this?

handkerchief’s picture

Project: Views (for Drupal 7) » Drupal core
Version: 7.x-3.x-dev » 8.9.x-dev
Component: Code » views.module

Based on #17, this is the simplest workaround:

(function ($, Drupal, drupalSettings) {
  Drupal.behaviors.exampleReset = {
    attach: function (context, settings) {

      let $resetLink = $('.views-exposed-form input[data-drupal-selector="edit-reset"]');
      $resetLink.click(function(){
        window.location.replace('https://' + window.location.hostname + window.location.pathname);
        return false;
      });

    }
  };
})(jQuery, Drupal, drupalSettings);

Core: 8.9.13

staceroni’s picture

I believe this is a duplicate issue of
https://www.drupal.org/project/drupal/issues/2844823

The workaround options are:
1. Do not group your views together (page, embed, block) to avoid the incorrect action value
2. Preprocess hook to fix the form action
3. Javascript behavior to fix the form action

There is no indication of a patch to verify, but if there were one, I think it would be on the other issue.
My assumption, although, in case anyone else is stumbling across this.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev
seeduardo’s picture

On our project using Drupal Core: 9.3.5, on an Export CSV view attached to a Block view the latter of which is using Better Exposed Filters, the 'Download CSV' button was working fine, but the 'Reset' button also triggered the CSV download.

The code in #106 worked for me to get round this (many thanks for that @handkerchief), but I tweaked it slightly, just to use the Drupal behaviors context variable:

(function ($, Drupal, drupalSettings) {
  Drupal.behaviors.resetButtonBehavior = {
    attach: function (context, settings) {
      $(context).find('.views-exposed-form input[data-drupal-selector="edit-reset"]').on('click', function(){
        window.location.replace('https://' + window.location.hostname + window.location.pathname);
        return false;
      });
    }
  };
})(jQuery, Drupal, drupalSettings);

The compromise, as many other posters in this issue thread have noted, is that the page reloads rather than just resetting the filters, but this is certainly better than the faulty behaviour of the 'Reset' button beforehand. I still feel a better solution needs to be incorporated into Core at some point.

I also reaffirm what @staceroni writes in #107 and will cross-post on that other useful issue thread mentioned there.

markabur’s picture

Still using #66 in d7.

jglynn’s picture

For Drupal 9, #110 didn't work for me. I used the following in my js file:

(function ($) {
	$(document).ready(function () {
		//
		// code to fix reset button issue on views filters jumping to wrong display  https://www.drupal.org/project/drupal/issues/1109980
		$(document).delegate(
			".views-exposed-form input[data-drupal-selector='edit-reset']",
			"click",
			function (event) {
				event.preventDefault();
				window.location.replace(
					"https://" + window.location.hostname + window.location.pathname
				);
				return false;
			}
		);
		//
	}); //end document ready
})(jQuery);

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

acbramley’s picture

Status: Needs work » Closed (duplicate)
Issue tags: +Bug Smash Initiative

This is being triaged as part of bug smash. This issue duplicates an existing issue which has a WIP fix on it.

This is a duplicate of #3163940: Viewsform has incorrect form submit URL if loaded through ajax