Mozilla incrementally remembers form field values

RESOLVED DUPLICATE of bug 140697

Status

()

Core
Layout: Form Controls
P4
critical
RESOLVED DUPLICATE of bug 140697
16 years ago
16 years ago

People

(Reporter: Jerry Baker, Assigned: Alexandru Savulov)

Tracking

({dataloss})

Trunk
Future
x86
Windows XP
dataloss
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
2002082308 trunk

1) Visit a page with multiple input fields for a form.
2) Fill the fields out and submit the form.
3) Press back button to return to the form.

Result: one text field will have the text you entered and the rest will be
blank. If you go through the steps again, there will be two text fields that
remember their text. Rinse, repeat.
(Assignee)

Comment 1

16 years ago
reporter:

please attach a testcase, or the source of the page that caused the bug described.

thx!
(Reporter)

Comment 2

16 years ago
You can see it with Bugzilla.

If you fill out two or more fields in a form, submit it, then press the back
button, only one field is remembered.
(Reporter)

Comment 3

16 years ago
I should note that this seems to apply only to <input> tags. <textarea> does not
appear to have Mozilla-induced amnesia.
(Assignee)

Comment 4

16 years ago
reporter, 
please tell us at least an URL where you encountered this problem. thx!
(Reporter)

Comment 5

16 years ago
I'm sorry. I thought you would know where to go if I said Bugzilla.

http://bugzilla.mozilla.org/query.cgi.

Fill in two or more <input> tags in your query and run it. When it returns the
query press the back button. You will see that only one text input "remembers"
the fields stored in it.

Comment 6

16 years ago
This works fine on build 2002-09-03-08-trunk... can you still see the problem
with newer builds? 
(Reporter)

Comment 7

16 years ago
Appears to be working. Will check back in a few days and mark WFM if still working.

Comment 8

16 years ago
WFM using 2002091908-trunk.
Closing as WFM per comment 7.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 9

16 years ago
verifying
Status: RESOLVED → VERIFIED
(Reporter)

Comment 10

16 years ago
This is happening again with 2002101808 trunk.

Go to google, type in a search, press search button, press back. Search field is
empty.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Comment 11

16 years ago
i tested with 2002102408 on 2K and is working. WFM?
Priority: -- → P4
Target Milestone: --- → Future

Comment 12

16 years ago
I have this bug on 2002102908/NT4.

1. Go to http://trizland.ru/search.php
2. Check ALL the checkboxes. 
3. Click submit button at the bottom of the page.
4. Wait until the search result page loads.
5. Press Alt-Left (or browser Back button)
6. Note that last checkbox in each table is unchecked.

It looks a lot like a good old "for(i=1;i<N;i++) vs. for(i=1;i<=N;i++)" bug.


Updated

16 years ago
Severity: normal → major
Keywords: dataloss

Comment 13

16 years ago
I see it, this looks like a layout history problem. CC: jkeiser

Comment 14

16 years ago
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: major → critical
This is due to the hidden input at the beginning.  Disturbing.  Duplicate of 140697.

*** This bug has been marked as a duplicate of 140697 ***
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Component: Form Submission → Layout: Form Controls
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.