User-Agent: Mozilla/5.0 (X11; U; Linux i686; cs-CZ; rv:1.8b) Gecko/20050217 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; cs-CZ; rv:1.8b) Gecko/20050217 Form fileds are nto filled correctly when form is submited and then back button is pressed. Reproducible: Always Steps to Reproduce: 1.On URL fill whatever you want to form fields 2.press button "Vyhledat" 3.press Back Actual Results: The fields are filled incorrectly (some of them are correct some of them are empty), radio buttons are messed up. Expected Results: Same as with 1.7.5. Corretly filled form.

Might it be that this doesn't happen when one disables JavaScript?

testcase exhibits the bug with linux suite trunk 2005031005 load the testcase, enter something in the textbox, reload ==> textbox clears

this regressed between linux trunk 2004103105 and 2004110106, apparently bug 204784

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050312 I don´t see the bug on the testcase, maybe Linux only, though bug 204784 was OS: All On Reload the contents of the textbox is unchanged, on Shift-Reload it clears.

This is a known issue with form state restoration.... The problem is that we save state at document teardown, and restore when the element is created. Part of the key that identifies the form control is the position of the form control in the form. In this case, that position is _different_ at the two points in time (at teardown, it's at position 1, while at creation it's in position 0). The position used to be identical because of bug 204784, since "position in form" didn't get updated when the object was added. I'm not sure there's anything sane to do here short of coming up with a better way of identifying "the same form control".... or caching the DOM on back/forward, of course. ;)

In short: fixing bug #204784 broke this?

In short, it's been broken all along in various cases. Fixing bug 204784 caused this particular testcase to have issues, but I can easily write a slightly different testcase that has issues both now and before bug 204784. I can also write a slightly different testcase that has problems before bug 204784 but was FIXED by that bug. The core problem, again, is that it's really impossible to tell, in general, when a DOM node in one DOM is "the same" as a DOM node in another DOM when the DOMs are not static.

(In reply to comment #7) > The core problem, again, is that it's really impossible to tell, in general, > when a DOM node in one DOM is "the same" as a DOM node in another DOM when the > DOMs are not static. Shouldn't this be determined by the "name" attribute of a field (where it exists)? I've encountered what appears to be the same bug -- I'm relocating an input field in a form with some javascript, and all the input fields following it in the DOM fail to be filled when the page is reloaded. See the attachment "testcase 2".

> Shouldn't this be determined by the "name" attribute of a field This is not guaranteed to be unique. In fact, quite the opposite. For example, all radio buttons in a radio group will have the same name. Only one of them may be selected at any given time. > See the attachment "testcase 2". Worksforme -- reloading doesn't change the form state (current trunk seamonkey build, bfcache enabled).

(In reply to comment #2) > Created an attachment (id=177211) [edit] > testcase > > testcase exhibits the bug with linux suite trunk 2005031005 > > load the testcase, enter something in the textbox, reload > ==> textbox clears It happens on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051109 Firefox/1.6a1 too. OS -> All

I had this problem on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051109 Firefox/1.6a1 at Google and some other pages I forgot on a recent trunk build. Hitting Backspace to go back in Google loses the query word in the original page. Unfortunately, it's not reproduceable in my case, though. It happens sometimes, not always. Data in checkboxes and dropdown boxes are not lost, but only text in input fields are lost. It seems this started to happen after October, as I updated it from a trunk build of September to a recent trunk build in November.

I am unable to reproduce this issue on Version 47.0b5 Build ID 20160512003946 User Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Closing this bug as resolves:work for me. Feel free to reopen if you encounter this issue on the current Firefox versions.