4

I've been trying to find a workaround to the back button bug in Safari/Chrome (browser putting bogus data in fields where they don't belong). I haven't had any luck, and it seems like there should be a good solution to this by now (I see posts about this going back to 2009, but no good solution).

In this example: http://jsfiddle.net/eGutT/13/

you can see that everything is fine on the initial page load. However, after clicking the link, then clicking the back button on the browser, values are propagated the the wrong fields. Please use Safari or Chrome to test. It works fine on Firefox.

This is a very serious problem, especially when:

  1. User goes hits the back button, and this bug occurs
  2. User doesn't notice the bogus data
  3. User makes some unrelated change to the form (in a different unaffected field)
  4. User submits form

Now you are left with a situation where the bogus data is committed to the database!!

BTW, this problem may be related to jQuery, since if you uncomment this line in the example:

updateRowNums();  // IF YOU COMMENT OUT THIS LINE...

no extra/bogus data gets introduced.

Thanks, Galen

Galen
  • 491
  • 4
  • 15
  • 1
    possible duplicate of [jQuery finding wrong elements under Chrome](http://stackoverflow.com/questions/4823457/jquery-finding-wrong-elements-under-chrome) – PetersenDidIt Jan 28 '11 at 18:42
  • Thanks, you have solved the issue on the other post. Although having a name attribute is a workaround, it is still a webkit bug. In other words, if webkit is unsure about a field to populate, it shouldn't arbitrarily pick one :) – Galen Jan 28 '11 at 19:02
  • Just in case users run into this question still today: learn about **bfcache** (e.g. via [this blog post](https://web.dev/bfcache/)) and see [here](https://stackoverflow.com/a/68606072/3991164) how to hook in some code to tidy up the prior page state. – flaschbier Jul 31 '21 at 22:11

1 Answers1

0

Are you talking about the 0, 1, and 2? Because your function updateRowNums is automatically forcing those values. If you want to maintain that first column, you could change updateRowNums to something like this:

if (!$('#some_id').val()) { $('#some_id').val(x); }

(Obviously it's not the most efficient code, but it resets the field if no value is present.)

However, if that isn't what you're talking about, then I couldn't reproduce your problem. I'm using Chrome 9.0.597.83, and it saved all the right data in all the right places.

sdleihssirhc
  • 42,000
  • 6
  • 53
  • 67
  • Hmmm, I'm using that same exact build of Chrome on the Mac. The problem isn't that I don't want to set a value that's already set (like you suggested). The problem is that when you come back to the page, other unrelated fields (with completely different IDs) take on the values of the other fields. This actually has nothing to do with jQuery, as I've discovered. This example doesn't use jQuery, and has the problem: http://jsfiddle.net/rwaldron/UvmDv/7/ – Galen Jan 28 '11 at 19:08