Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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:
Comments
Comment #1
dawehnerCan you please try out the beta release? There are so many things fixed it's impossible to count/remember
Comment #2
esmerel CreditAttribution: esmerel commentedComment #3
brandy.brown CreditAttribution: brandy.brown commentedI 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.
Comment #4
vlooivlerke CreditAttribution: vlooivlerke commentedSame problem here with exposed form filters and Ajax
Works with Ajax and exposed forms if filters are not exposed.
Comment #5
brandy.brown CreditAttribution: brandy.brown commentedvlooivlerke are you using the Better Exposed Filters module?
Comment #6
vlooivlerke CreditAttribution: vlooivlerke commentedno, Let me have a look at it thanks.
I am building a view and will post link for all to see soon.
Comment #7
gregglesComment #8
Todd Young CreditAttribution: Todd Young commentedI 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.
Comment #9
vlooivlerke CreditAttribution: vlooivlerke commentedHere 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)
Comment #10
dawehnerI'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.
Comment #11
vlooivlerke CreditAttribution: vlooivlerke commentedThe 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
Comment #12
thoughtcat CreditAttribution: thoughtcat commentedI 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.
Comment #13
rlangille CreditAttribution: rlangille commentedI 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.
Comment #14
stongo CreditAttribution: stongo commentedIn 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.
Comment #15
brandy.brown CreditAttribution: brandy.brown commentedas 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.
Comment #16
jh81 CreditAttribution: jh81 commentedSame 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.
Comment #17
alx_benjamin CreditAttribution: alx_benjamin commentedI 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.
Comment #18
jh81 CreditAttribution: jh81 commentedFor #17, how/where are you adding the jQuery code for the fix?
Comment #19
erin814 CreditAttribution: erin814 commentedHaving 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.
Comment #20
esmerel CreditAttribution: esmerel commentedComment #21
osopolarSomehow 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:
Comment #22
osopolarNow 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']?
Comment #23
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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.
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!.
Comment #24
corvus_ch CreditAttribution: corvus_ch commented[#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.
Comment #25
warmth CreditAttribution: warmth commentedI'm having the same issue, subscribing...
Comment #26
mstef CreditAttribution: mstef commentedReset not working for me with AJAX views. I get an endless redirect when clicked.
Comment #27
damiankloip CreditAttribution: damiankloip commented@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
Comment #28
mstef CreditAttribution: mstef commentedah - i thought i had the latest dev in, so I didn't see that issue. thanks damian.
Comment #29
dawehnerSo is it just me, or can we mark this issue as fixed?
Comment #30
damiankloip CreditAttribution: damiankloip commentedWell 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.
Comment #31
iLLin CreditAttribution: iLLin commentedThis 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.
Comment #32
iLLin CreditAttribution: iLLin commentedComment #33
GBain22 CreditAttribution: GBain22 commentedI 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?
Comment #34
iLLin CreditAttribution: iLLin commentedYou can use the same approach as #21. Just change it to your display name.
Comment #35
Anonymous (not verified) CreditAttribution: Anonymous commentedThat sounds as a conflict problem are you adding the jquery as drupal standards?
more info https://drupal.org/node/171213
Comment #36
bcobin CreditAttribution: bcobin commentedSame 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!
Comment #37
Anonymous (not verified) CreditAttribution: Anonymous commentedAre you using the jQuery update module? because I'm not and my solution #23 is just working fine.
Comment #38
bcobin CreditAttribution: bcobin commentedThank 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!
Comment #39
Anonymous (not verified) CreditAttribution: Anonymous commentedMy pleasure :)
Comment #40
Anonymous (not verified) CreditAttribution: Anonymous commentedChanging the priority to minor since there is a workaround.
Comment #41
bcobin CreditAttribution: bcobin commentedOne 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...
Comment #42
cm1se7en CreditAttribution: cm1se7en commentedThanks osopolar #21
I'm OK with
$form['#action'] = current_path();
Comment #43
Anonymous (not verified) CreditAttribution: Anonymous commented@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.
Comment #44
PTL CreditAttribution: PTL commentedThank you for your code from #23. I can solve it now.
Comment #45
bcobin CreditAttribution: bcobin commented@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!
Comment #46
tsonye CreditAttribution: tsonye commentedI 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!
Comment #47
Anonymous (not verified) CreditAttribution: Anonymous commentedHi, 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
Comment #48
jh81 CreditAttribution: jh81 commentedThe 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.
Comment #49
boregar CreditAttribution: boregar commentedThe 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.
Comment #50
jh81 CreditAttribution: jh81 commented@hillmore, I was able to get this working following your directions. Thanks!
Comment #51
pixel6 CreditAttribution: pixel6 commentedThe code in #23 worked fine for me too! Thanks.
Comment #52
jamesdixon CreditAttribution: jamesdixon commentedCode #23 was close to working for me, but was not reseting text fields. The following snippet got the reset button working for me:
Comment #53
stongo CreditAttribution: stongo commentedAll 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
Comment #54
PhilYHi,
#52 doesn't seem to work with Better Exposed Filters but only on regular Views filters
Comment #55
PhilYHere 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):
Hope this will help some readers ;-)
PS: no need of module hack or js/jQuery script
Comment #56
i.bajrai CreditAttribution: i.bajrai commentedI 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?
Comment #57
phoang CreditAttribution: phoang commentedFor 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.
Comment #58
Anonymous (not verified) CreditAttribution: Anonymous commented@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?
Comment #59
kunkunkun CreditAttribution: kunkunkun commentedIt also happens when using exposed filter in a view content pane.
Comment #60
AnybodyHere 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.
Comment #61
jennypanighetti CreditAttribution: jennypanighetti commentedThe code in #52 was the only one that worked for me. Thank you, combination of commenters!!
Comment #62
mxlav CreditAttribution: mxlav commented#60 worked nicely thanks @Anybody!
Comment #63
jelo CreditAttribution: jelo commented#60 worked nicely for me as well. Thanks!
Comment #64
jelo CreditAttribution: jelo commentedI 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...
Comment #65
darvanen#55 did the trick for me, thanks @PhilY!
Comment #66
franksj CreditAttribution: franksj at Breakthrough Technologies, LLC commentedWe 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:
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.
Comment #67
darvanenSo simple. Thanks franksj, worked for me (on another site where I couldn't use #55).
Comment #68
phileas75 CreditAttribution: phileas75 commented#52 works for me ! Thx
Comment #69
mobius_time CreditAttribution: mobius_time commentedThank you, PhilY, your solution at #55 using that module worked for me!
Comment #70
dgtlmoon CreditAttribution: dgtlmoon commented#55 worked for me, but I'm unsure if this is a fix or just a workaround
Comment #71
darvanenIt's a workaround, but, to be honest, with D8 released we may not be that likely to get a fix for this in D7.
Comment #72
milos.kroulik CreditAttribution: milos.kroulik commentedWorkaround from #55 works also with Views content panes. But it would be great, if there would be a way to change URL.
Comment #73
Alina Basarabeanu CreditAttribution: Alina Basarabeanu commentedUsing a view without a url and BEF the only solution was #66. Thanks
Comment #74
capfive CreditAttribution: capfive commentedGreat fix with the javascript! Thanks this really helped! (#66)
Comment #75
Alauddin CreditAttribution: Alauddin commented#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.
Comment #76
weynhamzGet 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?
Comment #77
scotwith1tAlso implemented #66 for its simplicity. Thanks!
Comment #78
nmalinoski CreditAttribution: nmalinoski commentedURL 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).
Comment #79
amogiz CreditAttribution: amogiz commented#66 works perfect for me.
Great thanx !!!!!!!
Comment #80
amogiz CreditAttribution: amogiz commented#66 works perfect for me.
Great thanx !!!!!!!
Comment #81
acrosmanI 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.
Comment #82
diamondseaI 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).
Comment #83
neilsavage CreditAttribution: neilsavage as a volunteer commented#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:
Comment #84
jasonflaherty CreditAttribution: jasonflaherty commentedI 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!
Comment #85
andriarijaona CreditAttribution: andriarijaona commentedSocial 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
Comment #86
joelpittetHmm not sure what that change of title was all about...
Comment #87
maxplus CreditAttribution: maxplus commentedHi,
working with views content panes and views filters with ajax: #66 helped me out, thanks!
Comment #88
alibenski CreditAttribution: alibenski commentedHello,
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.
Comment #89
e.ryan.schmidt@gmail.com CreditAttribution: e.ryan.schmidt@gmail.com commented#52 worked great! Thank you!
Comment #90
arunkumark+1
The patch #52 working perfectly to reset exposed form. Am using exposed form in my CTools popup, it works as expected.
Comment #91
AporieThanks #60 worked for me.
Comment #92
ogomez78 CreditAttribution: ogomez78 commentedI'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:
Comment #93
markabur CreditAttribution: markabur commentedThanks, using #66
Comment #94
axion CreditAttribution: axion commentedIn 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
Comment #95
axion CreditAttribution: axion commentedI 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.
Comment #96
dalemoore CreditAttribution: dalemoore commentedConfirmed #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!
Comment #97
rpataca CreditAttribution: rpataca commented#57 worked great. Worked on Drupal 8 !
Thanks @phoang
Comment #98
osab CreditAttribution: osab as a volunteer and at AnyforSoft, Drupal Ukraine Community for Drupal Ukraine Community commentedusing #66, works perfectly! Views version: 7.x-3.20
Comment #99
bmsomega CreditAttribution: bmsomega commented#52 works like a charm for me! Thanks @jamesdixon!
Comment #100
Anonymous (not verified) CreditAttribution: Anonymous commented#66 works still. To me this looks like the most simple way around this problem. Thanks!
Comment #101
GuyManDude CreditAttribution: GuyManDude commentedI 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.
Comment #102
someshver CreditAttribution: someshver commented#23 solved my problem. Thanks
Comment #103
robbdavis CreditAttribution: robbdavis commented@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.
Comment #104
jamesdixon CreditAttribution: jamesdixon at Dialed In Design commentedHahaha @robbdavis thanks for brightening my day bud! Glad I could help you out :)
Comment #105
Shrutidkadam CreditAttribution: Shrutidkadam commented#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?
Comment #106
handkerchiefBased on #17, this is the simplest workaround:
Core: 8.9.13
Comment #107
staceroni CreditAttribution: staceroni as a volunteer commentedI 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.
Comment #110
seeduardo CreditAttribution: seeduardo at Cyber-Duck commentedOn 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: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.
Comment #111
markabur CreditAttribution: markabur commentedStill using #66 in d7.
Comment #112
jglynn CreditAttribution: jglynn commentedFor Drupal 9, #110 didn't work for me. I used the following in my js file:
Comment #116
acbramley CreditAttribution: acbramley at PreviousNext commentedThis 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