285730 - form is not filled correctly when going back or on reload, if DOM is modified

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect)

Description

[Adam Pribyl]

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.

Comment 1

[Frank Wein [:mcsmurf]]

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

Comment 2

[Andrew Schultz]

Attachment: testcase - on reload textbox clears

testcase exhibits the bug with linux suite trunk 2005031005

load the testcase, enter something in the textbox, reload
  ==> textbox clears

Comment 3

[Andrew Schultz]

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

Comment 4

[Hermann Schwab]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

Comment 6

[Adam Pribyl]

In short: fixing bug #204784 broke this?

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 8

[andy]

Attachment: testcase 2

(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".

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Ryuichi KUBUKI]

(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

Comment 11

[Ryuichi KUBUKI]

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.

Comment 14

[joshua]

I've also experienced this problem.

When I tested the contact us form on this site, http://www.noves.org/article/15/contact-us, filled only in part of the required info and submitted the form I was sent to page that said

"Submission Failed

The form was not submitted for the following reasons

    Missing: email
    Missing: antispam"

So I clicked on the return link it took me back to the page I started from however all the fields were empty.

When I hover of the Return link this is what I see javascript:window.history.back(-1).

Thank you for your help! GH#1237

Comment 15

[Kanchan Kumari QA]

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.