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

Files: 
CommentFileSizeAuthor
#32 interdiff-1786904-31-32.txt5.79 KBacrollet
#32 views-ajax_history-1786904-32.patch6.96 KBacrollet
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views-ajax_history-1786904-32.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#31 views-ajax_history-1786904-31.patch5.1 KBacrollet
#27 views-ajax-history.patch5.18 KBmatt2000
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views-ajax-history.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#3 views_ajax_submit_back.patch4.57 KBmatt2000
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views_ajax_submit_back_2.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#2 views_ajax_submit_back.patch4.47 KBmatt2000
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views_ajax_submit_back_1.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#1 views_ajax_submit_back.patch2.04 KBmatt2000
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views_ajax_submit_back_0.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
views_ajax_submit_back.patch1.77 KBmatt2000
PASSED: [[SimpleTest]]: [MySQL] 1,555 pass(es).
[ View ]

Comments

StatusFileSize
new2.04 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views_ajax_submit_back_0.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Same code, more comments.

Title:Reload results from AJAX submit of exposed filters when using the browser's back buttonReload results from AJAX submit when using the browser's back button
Component:exposed filters» User interface
StatusFileSize
new4.47 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views_ajax_submit_back_1.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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

Issue summary:View changes

Update steps to reproduce to include pager.

StatusFileSize
new4.57 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views_ajax_submit_back_2.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

New patch fixes a bug with page 0.

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

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.

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.

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

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

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.

@sanderj

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

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

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.

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.

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

Hello to everybody,

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

Hello to everybody,

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

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?

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.

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

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.

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.

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

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.

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

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?

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

Title:Reload results from AJAX submit when using the browser's back buttonDeep link filter settings & Reload results from AJAX submit when using the browser's back button
StatusFileSize
new5.18 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views-ajax-history.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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.

Has anyone tried Matts patch yet?

Issue summary:View changes

Note about initial patch.

subscribing!

Issue summary:View changes
StatusFileSize
new5.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.

Status:Needs work» Needs review
StatusFileSize
new6.96 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views-ajax_history-1786904-32.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
new5.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.

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

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');

3: views_ajax_submit_back.patch queued for re-testing.

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

1: views_ajax_submit_back.patch queued for re-testing.

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