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

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
15 years ago
3 years ago

People

(Reporter: covex, Unassigned)

Tracking

(Blocks 1 bug, {regression, testcase})

Trunk
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(2 attachments)

Reporter

Description

15 years ago
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?

Comment 2

15 years ago
testcase exhibits the bug with linux suite trunk 2005031005

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

Comment 3

15 years ago
this regressed between linux trunk 2004103105 and 2004110106, apparently bug 204784
Assignee: general → pkwarren
Status: UNCONFIRMED → NEW
Component: General → Layout: Form Controls
Ever confirmed: true
Keywords: regression, testcase
Product: Mozilla Application Suite → Core
Version: unspecified → Trunk

Comment 4

15 years ago
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.  ;)
Reporter

Comment 6

15 years ago
In short: fixing bug #204784 broke this?
Summary: form is not filled correctly when going back → form is not filled correctly when going back or on reload
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.

Updated

15 years ago
Assignee: pkwarren → nobody
QA Contact: general → layout.form-controls

Updated

14 years ago
Blocks: 252729

Comment 8

14 years ago
Posted file 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".
> 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

14 years ago
(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
OS: Linux → All

Comment 11

14 years ago
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.
Duplicate of this bug: 342653
Duplicate of this bug: 175289

Updated

11 years ago
Attachment #177211 - Attachment description: testcase → testcase - on reload textbox clears
Target Milestone: --- → mozilla2.0
Target Milestone: mozilla2.0 → ---
Comment hidden (me-too)

Updated

5 years ago
Summary: form is not filled correctly when going back or on reload → form is not filled correctly when going back or on reload, if DOM is modified
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.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.