Testing Environment:
*Firefox 12
*Chrome 21

Steps to Reproduce:

1. Visit a page with a view that has exposed filters and/or pagers with auto-submit by AJAX.
2. Click an exposed form element to trigger a submission and provide results and/or use pagers.
3. Click some link to navigate to another page.
4. Click the back button to return to the view.

Actual Results: The selection made in step 2 is preserved, but the results are not as they were after step 2.

Expected Results: The View should show the same results as it it did after step 2.

Proposed solution: On ajaxComplete and on click of pager links, append the HTML id of the exposed form and the current page to the url as a #hash so it will be preserved by browser; and on page load, trigger the AJAX submit of the form id contained in the URL hash.

Patch attached. (Initial patch supports only filters. See below for patch with both filters & pagers.)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

matt2000’s picture

Same code, more comments.

matt2000’s picture

Title: Reload results from AJAX submit of exposed filters when using the browser's back button » Reload results from AJAX submit when using the browser's back button
Component: exposed filters » User interface
FileSize
4.47 KB

Here's a version that supports both filters and pagers, so naturally, its signficantly more complex than the previous versions.

matt2000’s picture

Issue summary: View changes

Update steps to reproduce to include pager.

matt2000’s picture

New patch fixes a bug with page 0.

dawehner’s picture

I did saw your patch all the time, but i'm not sure how to deal with it at the moment.
On the one hand i totally see the bug you have but on the other hand your code does quite a lot of things.

Some questions i have in mind: how to handler the case that there are existing fragments in the url,
you know i'm really concerned about breaking existing views behaviour.

Adds a reference for a related discussion: #343535: Enable bookmarking of AJAX views

matt2000’s picture

What else uses URL fragments?

I've provided a utility function (Drupal.Views.updateLocationHash) that allows storing an arbitrary number of key-value pairs in the fragment, so if anything else in views front-end uses the fragment, it will be trivial to convert it to use this new function.

matt2000’s picture

Also, if the current patch is too big to review at once, just start with the patch in #1. It's fully functional for use with exposed filters only. We can then do the rest as a follow-up. However, it does NOT support unlimited fragment key-values, so you may want the more complete version anyway.

dawehner’s picture

Just an example: overlay. Read #1440628: [Meta] javascript toolbar/tableheader with url fragment mess for more examples of possible issues just in core.

matt2000’s picture

My technique for handling hashes/fragments is compatible with overlay. I've tested and verified this.

SanderJP’s picture

Hello there, thanks for the time to make this, I'm very interested to see it work!
But this does not work when you have two views with ajax pagers on one page. I have not tested it on a clean install yet, I can if needed.

matt2000’s picture

@sanderj

That's correct. This solution does not yet support that use case.

schmidtk’s picture

Works fine for me on FIrefox 16.0.1, but on Chrome 22.0.1229.79 I could put it into a state of never ending ajax post's pretty easily. To replicate: filter a view for something, click one of the links, then press the back button.

After its in the never ending ajax posts, pressing the stop button generates an alert with:

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /views/ajax
StatusText:
ResponseText:
ReadyState: 4

schmidtk’s picture

I was also able to generate a never ending string of AJAX Posts in Firefox and Chrome by filtering for something, then clearing the filter by selecting the text in the filter box and pressing backspace.

AdamGerthel’s picture

Would it be possible to combine this with the html5 History API? Hash bangs are OK, but for future use (i.e. when IE7+8 are out of the picture) the history API should be used.

fotisp’s picture

Hello there,
can anyone pls help to "fix" this for d6 views2 ?
Its strange that there are no topics about that for the above versions....!
thx
f

aze2010’s picture

Hello to everybody,

do anybody know how this will work with Drupal6 and latest Views3 dev?

aze2010’s picture

Hello to everybody,

do anybody know how this will work with Drupal6 and latest Views3 dev?

willwillwill’s picture

Hello, not sure if this should be a new post or in this thread.
I have a similar problem. I have a model site on drupal 7 where multiple auto-submit filters sort out a type of model. i.e.. female blond caucasian etc.
Thumbnails show the sorted selection. Clicking on the thumbnail takes you to a profile. The next step is to return to the sorted thumbnails with history back.
On chrome the filtered selection is gone on history back. (has become unfiltered again) While with safari, firefox, iphone, ipad, the filtered selection remains (in the exact scrolled position). Is there a way to make the filtered selection stick and remain on history back with chrome?

ajlozier’s picture

For those who are using Safari and have found that no-cache headers and the onunload attribute still seem to not resolve the problem, I would encourage you to check out this blog post I just wrote:

http://www.informationarchitech.com/blog/safari-auto-complete-bug-affect...

What I eventually figured out was that Safari was "restoring" the previous form_build_id (even if the page was NOT loaded from cache) which in turn was triggering the ajax error (re-use of a "one time use" token)

Hopefully this will save others the hours of struggle I went through to figure it out!

I am also reposting this comment on a few other issue reports which seem similar.

ice70’s picture

Hi ajlozier,

thank you for the post. In the blog there is a reference to a patch, which is for the drupal commerce module. Do you have any pointers on how to go about adding this in the views exposed filters / ajax context?

thank you for your help,
ice70

pianomansam’s picture

Version: 7.x-3.5 » 7.x-3.6
Status: Needs review » Needs work

I would have loved to see this work! However, the patch did not cleanly apply to 7.x-3.6 and after manually applying it, I immediately ran into a never ending AJAX loop. My view only has a content type filter and pagination.

askibinski’s picture

Status: Needs work » Needs review

@pianomansman I think you had some trouble applying the patch.

The patch at #4 applies cleanly to views-7.x-3.7 or current dev. I tested it with 3.7 and it works nicely as described with ajax pagers without any errors/loops.

pianomansam’s picture

Version: 7.x-3.6 » 7.x-3.7

@askibinski If the patch applied cleanly to 3.7, let's keep track of what version it applies to. As of my testing, this issue was assigned to 3.5 so my assumption with the patch not cleanly applying to 3.6 was that the patch was for 3.5

2ndChanceTech’s picture

I have tested the patch in #3, and some functionality I would expect, seems to be missing.

1 - If you have a full pager, and click page 2, 3, 4, and then press back the #hash changes in the url appropriately, however the view stays the same.

2 - If you have a pager with a "Last" option, and click to another link, when pressing back it goes to the first page (similar to before the patch).

Otherwise all seems to be working well as expected.

mvlabat’s picture

Have the same issue as kryptic. Is there any solution?

andros’s picture

I would really appreciate this functionality in Views in a better form.

Actually I think ajax is only useful if it has has this functionality.

Ajax is useful specially for big sites for both, users and the Webmaster. But if the browser is not updated about what the user is actually doing, this means a huge feature loss, and a real disadvantage for the user, which is offensive for users.
I really wonder why this functionality is not already part of the views project?

matt2000’s picture

#2: views_ajax_submit_back.patch queued for re-testing.

matt2000’s picture

Title: Reload results from AJAX submit when using the browser's back button » Deep link filter settings & Reload results from AJAX submit when using the browser's back button
FileSize
5.18 KB

He's an updated patch that (crudely) adds actual deep-linking of AJAX Filter selections, and works with Views 7.x-3.7.

Note that I'm testing with jQuery 1.8 (via jQuery Update) and with Ajax auto-submit of Filters enabled. Otherwise, YMMV.

I'm still using window.location.hash, which ought to be updated to HTML5 PushState. But this is the quick make-it-work pass.

I anticipate that this also solves people issues with looped reloading. I suspect it was caused by modifications to Views tpls; yours or mine. Now we do $('body').once for the crucial functions, so repeats should be unconditionally prevented.

Status: Needs review » Needs work

The last submitted patch, views-ajax-history.patch, failed testing.

AdamGerthel’s picture

Has anyone tried Matts patch yet?

AdamGerthel’s picture

Issue summary: View changes

Note about initial patch.

aze2010’s picture

subscribing!

acrollet’s picture

Issue summary: View changes
FileSize
5.1 KB

Updated version of #27 attached that should play nicely with the testbot. (Otherwise unchanged) I've reviewed this patch, and the issue with going back after clicking the 'Last' link is fixed. However, clicking the 'back' button will update the URL fragment, but not refresh the page.

acrollet’s picture

Status: Needs work » Needs review
FileSize
6.96 KB
5.79 KB

Updated patch attached, with interdiff. This one solves the back button issue for me. Changes from #31:

* Moves the reaction code to a separate callback.
* Uses the hashchange event to detect when the back button is pressed and update the view.
* Handles the case of being on a different page of the view and pressing the back button until there is no hash.
* Unset any empty parameters (e.g. query="") when setting the hash to avoid adding unnecessary extra parameters to the hash
* Only set a new hash if it differs from the previous hash
* includes misc/jquery.ba-bbq.js to gain access to the deparam() method

There is still at least one issue, being that exposed filters and the back button still don't play nicely. Need to step away though, so submitting these updates for review.

The last submitted patch, 32: views-ajax_history-1786904-32.patch, failed testing.

acrollet’s picture

The last submitted patch, 32: views-ajax_history-1786904-32.patch, failed testing.

askibinski’s picture

I've tested patch at #27 (after making it apply cleanly) and I tested the path at #34, both with latest -dev and 7.x-3.7 using jQuery 1.8 (jquery_update). But I can't get it working.

No errors either, but there is no page refresh after using the back button. I remain at the first page, and the url is like:

/myview#p=5&field_provincie_value=All&f=deelnemers-page

However, I should mention that I'm using a block view in combination with quicktabs. Still, the patch at #4 works, but it resulted in errors after upgrading to jQuery 1.8. I will try to investigate more.

Sidenote: I believe the patch at #34 should use:

drupal_add_library('system', 'jquery.bbq');

instead of:

drupal_add_js('/misc/jquery.ba-bbq.js');
xuanlang’s picture

3: views_ajax_submit_back.patch queued for re-testing.

The last submitted patch, 3: views_ajax_submit_back.patch, failed testing.

xuanlang’s picture

1: views_ajax_submit_back.patch queued for re-testing.

The last submitted patch, 1: views_ajax_submit_back.patch, failed testing.

prat’s picture

In my case I'm using filter option to preserve value in session, URL hash is formed correctly, but the actual page never gets selected.
Supplied patch selects the page in all cases, so use with caution. Applied against views 7.x-3.7

Status: Needs review » Needs work

The last submitted patch, 41: views-ajax_history-1786904-41.patch, failed testing.

prat’s picture

FileSize
4.29 KB

Disregard #41 patch, fails to be applied

prat’s picture

Added checkbox support for filters and pager handing based on history of browser back / forward click

prat’s picture

FileSize
6.3 KB

Left console.log function in the previous patch

quotesBro’s picture

Status: Needs work » Needs review

The last submitted patch, 31: views-ajax_history-1786904-31.patch, failed testing.

The last submitted patch, 43: views-ajax_history-1786904-43.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 45: views-ajax_history-1786904-45.patch, failed testing.

prat’s picture

Several improvements, setting false value for un-clicked checkboxes

Frederic wbase’s picture

I've tested the patch of #50 and for me it is working on a free text search exposed filter

quotesBro’s picture

Status: Needs work » Needs review
quotesBro’s picture

Status: Needs review » Needs work

The last submitted patch, 50: views-ajax_history-1786904-46.patch, failed testing.

mzwyssig’s picture

The patch #50 works for me as well. It would be great to be able to enable this functionnliaty in the ajax settings of any view !

BenMirkhah’s picture

#50 almost works perfect, thanks.
And almost because in case of multiple exposed filters
some drop-down select states were not remembered
but the view results seemed to indicate they were applied.

sushantpaste’s picture

Tried #50 patch with 7.x-3.11 it's not working when we tried to swap between pages from pager, it only changes the url but page is not getting refreshed.

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 50: views-ajax_history-1786904-46.patch, failed testing.

akosipax’s picture

Tried patch#50 and same result as #57: Ajax works and the URL is getting updated with the hash but using the back button loads the initial state (even though it does have the hash).

akosipax’s picture

I tried patch #32 and it works with one of my views that has a pager functionality. There are a couple of things to note:

* I had to add the pager__item class for it to work. Perhaps we can improve the patch to make the selector generic enough to work with any pager item link.
* It would not work with an exposed form that has radio buttons as a form element. It endlessly loops through the radio buttons. Again, perhaps we just need to tweak the selector to make sure it works with any views configuration.

I also added the bbq plugin through drupal_add_library but I'm not entirely sure if that's necessary for it to work.

albertski’s picture

Version: 7.x-3.7 » 7.x-3.x-dev
Status: Needs work » Needs review
FileSize
5.36 KB
11.21 KB

I ran into issues with the patch from #50 to work correctly on all my views.

I updated the code so it simply submits the ajax form. I removed the back/forward handler since it works prefectly without it.

I cleaned up the code. (Added missing semicolons, removed extra space, added function documentarians, and made coding standards fixes)

It works perfectly for me on multiple views.

Steps Taken to Test:

1. Create a view with exposed filters and a pager and set it to AJAX.
2. Navigate to the view and go to page 2.
3. Filter on all the exposed filters. (Make sure you still have items)
4. Click on an item.
5. Click back on your browser.
6. Verify that you are on the same page and all exposed filters are selected.
7. Update View and set Exposed Form to auto submit.
8. Redo Step 2 - 6.

albertski’s picture

Actually I found that if you had a textfield exposed filter it wouldn't work. Attached patch fixes that.

saurabh.dhariwal’s picture

I am using views 7.x-3.13. I haven't applied any of the patches mentioned above.

To solve this I had to check "Remember the last selection" and check all roles there in exposed filter settings. This solved the issue.

Steps to check this :

1 - Create a view with exposed form and ajax. Make sure "Remember the last selection " is unchecked.
2 - Navigate to view and filter
3 - Navigate to some other page
4 - Go back to views page using browser back button. Exposed filter shows last selected value but output is not for this.
5 - Edit view and check "Remember the last selection " in expose filter settings and save
6 - Repeat 2-4 steps.

Feel free to contact me incase of any query/concern regarding the same.

albertski’s picture

@saurabh.dhariwal I just tested again without patch on fresh install of Drupal and I am still seeing the issue. Yes I agree if you check "Remember the last selection", the last selected value is preselected, but the view does not show that till you press apply. Here is a way to test:

1. Create a view with a lot of nodes and exposed filters.
2. Set the view to ajax
3. Go to the view page
4. Select some filters so you get less results (but more than one page)
5. Go to page 2
6. Try to remember the results you have
7. Click on the first node
8. Press back on your browser
9. Notice that you are NOT on page 2 and you get the same results as you did on step 3 (even though your filters are selected).

Can you let me know if it still works? If so do you by any chance have any module enabled that is adding this functionality?

saurabh.dhariwal’s picture

@albertski, I tried your steps with clean install and its working fine for Firefox. On chrome, it has problem. Only additional setting I have is autosubmit for exposed filters.

After applying patch, it still doesn't work on chrome.

Thanks!

albertski’s picture

Thanks @saurabh.dhariwal. I also verified that it works with Firefox. I think Firefox does preserve this on it's own.

Hmm Can you let me know if you see any errors in console when in Chrome?

saurabh.dhariwal’s picture

@albertski, I am not getting any error on chrome console.

vistree’s picture

Hi @albertski,
thanx for the patch in #63. It works great in google chrome - where before I needed to hit the apply button to make the stored exposed filter values run.
But the patch does not work for Firefox. When I use the back button here I get

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /en/views/ajax
StatusText: error
ResponseText: 
ReadyState: 0

After this - the remembered values are resetted and the view shows all records (instead the former filtered results).

Should patch also work for IE9 and greater?

albertski’s picture

Status: Needs review » Needs work

I created a custom view and it works well in Chrome, Safari, and Firefox.

I tested the admin content view and if you select a filter and then select a page it gives me the Ajax error. I think if there was a way to run the if (window.location.hash) { only if the user came back via back button it would fix these issues.

nmalinoski’s picture

@albertski: Under what circumstances do you get hashes for AJAX views? The views I have that are affected by this issue are in blocks and do not modify the URL at all; there is no hash to grab filter criteria from.

albertski’s picture

@nmalinoski I am using view panes. And I have one view pane on a page in my scenario.

mrdrewkeller’s picture

I tested the patch in #63 on Chrome but I was not able to get it to work with or without autosubmit.

I don't see any errors in the console either.

I do see a string getting appended in the URL when the filters are selected ,

#edit-field-news-type-value=IN+THE+NEWS&p=11&f=news-views-block-1

However clicking on an item and then using the back button takes me back to the unfiltered page.

This was using Views 7.x.3.13

broeker’s picture

We recently ran into this issue on an Ajax view with exposed filters and the described problem with the back button:

When a user hits "back" they return to the search page with their exposed filter selections intact but without running the correct query.

On initial testing #63 solves the issue in Chrome (also working in FF).

These seems like a fairly significant issue if you want to leverage ajax views in search forms, as users commonly go back and forth. Perhaps there can be a push for this to get more review and pushed into dev branch?

shaunmilo’s picture

Patch from #63 only seems to partially work for me (although doesn't seem to work at all in Opera). While it remembers the very first filter and output when pressing the back button from a node, if you were to filter the view to something else and navigate to one of the nodes then press the back button again a second time, it only returns to the FIRST instance of the filtered view.

Running Views 7.x-3.16 & Drupal 7.54. Using an AJAX-enabled view (with an attachment inheriting exposed filters).

mmikitka’s picture

The attached patch uses the HTML5 History API instead of location.hash. Now, the URL is not altered such that it is possible to use a view with an exposed form in tabs with location.hash slugs.

This patch successfully passes the following scenarios:

  1. Single view per page, multiple form submissions, pager navigation, different page, then rewind history
  2. Multiple views per page, multiple form submissions on multiple views, pager navigation, different page, then rewind history
  3. Views in blocks or pages
  4. Reset button
broeker’s picture

+1 to mmikitka and patch #76

We will do further testing and report back but initial tests indicate this solves a very long-standing problem with Ajax views and history -- spectacular! We had been using Views Ajax History module (which kind of works for many use cases but not all) but we have now disabled that module as well, so far so good.

yeebot’s picture

Patch #76 works for me as well against Views 7.x-3.18

vistree’s picture

Patch #76 works fine if you use single select filters on exposed form. If you allow "multiselect" e.g. on a taxonomy field the back function does not work any more.
Also, if you use chosen module the back button work for single and multi select fields
EDIT: sorry - my problems have nothing to do with multi select or chosen module. All trouble seems to come from the views infinite scroll module!! Will debug and report back!

vistree’s picture

OK, problem was really related to views infinite scroll - so please ignore #79.
But I still have some problem in IE. @mmikitka: should this patch also work in Internet Explorer (e.g. 11)???

vistree’s picture

IE (ie11 in our case) had a problem on resetting the exposed filters. We fixed it by adding the following to patch in #76 (ajax_view.js):

@@ -272,3 +272,9 @@ Drupal.ajax.prototype.commands.viewsScrollTop = function (ajax, response, status
 };

 })(jQuery);
+
+jQuery(document).ready(function () {
+    jQuery(".views-exposed-form #edit-reset").click(function(){
+      history.pushState({}, '');
+    });
+});
ShaneOnABike’s picture

Wow this is amazing we seriously need to roll this into the actual release. Looks like I found one bug whereby if there are two exposed filters on the page (using Better Exposed Filters) the system gets a bit confused. It is not updating the links on each exposed filter to match properly.

DamienMcKenna’s picture

Assigned: matt2000 » Unassigned

FYI the "assigned" field is for indicating that you're actively working on an issue, if you're not actively working on an issue please leave it set to "unassigned". Thank you.

azovsky’s picture

#76 patch has been working for us for years. I think, it is ready for release.