Safari and Chrome modifying form data on back button

Question

I getting this weird issue in Safari & Chrome (works in Firefox and IE).

1. I start off with this checkbox list which has the first item 'A' checked, and item 'B' and 'C' unchecked
2. I then navigate to another page which orders the items that appear in the checkbox list
3. I change the order of the items in the list so it now goes 'B', 'A', 'C'
4. I press the back button
5. The page is re-fetched from the server (I have caching disabled), I check the response sent from the server, and the item 'A' is still checked and no longer the first item in the list.
6. !!!Weird Behaviour!!! The page has loaded in the browser with the new order 'B', 'A', 'C', but 'A' isn't checked, instead the first item 'B' is checked.

Somehow it appears that the position of the check item has been restored by pressing the back button, and the form data has been discarded that was sent from the server.

When I refresh the page the order is 'B', 'A', 'C' and item 'A' is now checked, and everything looks ok.

On both occasions the Page has IsPostBack set to false.

Is this a bug in web kit?

Tried, clearing the cache, going into private browsing mode, clearing the history. Still same behavior.

Answer 1

I found the same issue with Chrome. On further testing, I found it only happens if the website uses sessions. Whenever you press the back button, it removes any post data instead of reposting it.

I created a page to test it: http://www.duanehutchins.com/formtest.php If you type some info and post it a few times, it works. Then press back and reload; no data is reposted.

If I disable the session, it works fine. I reported the bug to Chrome. We'll see if anyone helps out.

Answer 2

We had a similar issue with form data being "restored" by Webkit, even though the page state changed in the mean time.

Similar post Safari and Chrome back button changes hidden and submit values in forms gave a good hint that worked for us. By adding autocomplete="off" to all forms on the page we could solve this.

Answer 3

See this example:

http://jsfiddle.net/eGutT/9/

This is happening to me as well. This seems like a pretty fundamental flaw as the use-case is so simple, and most likely common. I've already run into this issue in two places in different projects. If disabling the session actually avoids this issue, it's not a real fix, as most clients won't even know about this option, or care.