Add to cart form submit + redirect + user presses back button = broken ajax on cart form

If I'm not mistaken, the issue is that upon form submission, the form build ID is no longer valid (hence not found in the cache). What needs to happen on the "back" reload of the page is the browser should be instructed to reload it, causing the form to be rebuilt. Without that, the browser is presenting "stale" HTML - i.e. an invalid form. It's the equivalent of opening a form in a tab, logging out and back in in another tab, and then trying to submit that original form.

Ok, I thought there was something like that. Do you think we should consider adding that as an option to Commerce itself or perhaps a contrib module?

#4: 1621210-4-browser_cache_fix.patch queued for re-testing.

Not sure - all I can figure is maybe SimpleTest depends on the default header. Are we being over aggressive in this patch?

Actually, we're getting fails on other issues, too. Must be the testbot or a previous commit.

#4: 1621210-4-browser_cache_fix.patch queued for re-testing.

(fwiw, the fails were caused by a patch to Drupal 7.x-dev; the test bot always works against head, even though I don't. We got that rolled back.)

#4 solves as well other issue with using back button.

I've marked #1258266: Problems with defaulting to proper payment option in checkout page as duplicate.

#4 solves other issue with using back button.

#1874750: Force reload checkout redirection

I have been directed to this issue as mine is a duplicate at (http://drupal.org/node/1907164). I have tried the patch in #4 but with no success.

Can anyone confirm that this is still an issue?

As far as I know, it still is. More details from your comment in #15 would be helpful - namely, how did you test the patch and discern it to be failing? Could it have simply been that your JS wasn't loaded?

Hi I made a video demonstrating the bug at http://youtu.be/23ybwzoCM_Y ... Sometimes it's hard to put these things into words. The patch has been installed and yes JS is loading

I understand the nature of the bug, but thanks for the video demonstrating the patch isn't working. To be clear, though, this is a problem with browsers in general, not with the form itself. Perhaps we need a combination fix that attempts multiple approaches to accommodating back button browsing. So long as that page is being reloaded from the browser cache, though, we don't have any recourse in Drupal Commerce to force a rebuild of that form with the right options selected for attribute fields.

Just a quick update: This issue does not happen in IE 9

What do you mean with a combination fix? I assume you mean Commerce core and Drupal core?

If we can't force a form rebuild with the previous options can we just have it load a new page? (This is what IE does)

Found this post and might have some relevance http://drupal.org/node/1786904 I also applied the patch but did not solve the issue.

As per my comments #18 #20 #21 I believe this is still an issue so I'll mark it as need work.

We have posted an issue here that rszrama has mentioned seems to be a duplicate this issue possibly.
Here is our issue: http://drupal.org/node/1932124

Our Add To Cart Form breaks with or without Ajax enabled on the views page. For us a work around was to drop down from using the Content type ref. product to our Taxonomy ref. the add to cart form seems to be working well now but with Ajax enabled on any view of both types the Add to cart form breaks on both the view and the node type.

hope this helps a little...
big thanks to everyone in the drupal community for all the hard work and so many powerful features... drupal is a true testament to community:)

thanks:)

The problem with the patch in #4 is that browser's typically ignore cache headers for the back button (though if the user were to navigate to that page directly or via a link it would work). If the browser does listen to the cache, it only affects checkout pages so display nodes and views with the add to cart form would still be problematic.

We need a solution that allows the user to click the back button and still add the correct selected product to the cart. Whether this is something that can be resolved by commerce or needs attention in core I'm not sure.

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.

Hello

I am coming from https://www.drupal.org/node/1874750 and they say they need solved to solve the problem there. Any news? thanks