Closed Bug 140697 Opened 23 years ago Closed 3 years ago

Misplaced form element and hidden input element(s) break form value restoration when pressing Back

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: sgifford+mozilla-old, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug,
URL
)

Details

(Keywords: dataloss, testcase)

Attachments

(2 files, 1 obsolete file)

minimized testcase with explanation
1.58 KB, text/html
Details
original alexsavulov testcase :-)
814 bytes, text/html
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020422 BuildID: 2002042221 On this particular form, the contents of the form are lost when you submit it, then press "Back". This may be related to the fact that the form is an HTTP page, but is submitted to an HTTPS page. There are two similar bugs to this one (bug 62739 and bug 41555), but they don't seem to be quite the same. Reproducible: Always Steps to Reproduce: 1. Make sure you don't have any cookies stored for www.quotesmith.com 2. Visit http://www.quotesmith.com/cgi/indmed/qsindmedindex 3. Enter in your birth date in the top of the form. 4. Scroll to the bottom and hit "Continue". 5. When that page loads, hit Mozilla's "Back" button. 6. Press OK on the Security Warning dialog (if it comes up). Actual Results: The Birth Date field is reset to its default values. Expected Results: The information you entered staying in the Birth Date field. It doesn't seem to matter whether the Security Warning dialog is enabled or not.
dup of bug 138892?
Yes it seems to be a dup of 138892. Can anyone mark it as Resolved Duplicate ? I don't think I have right to do this.
dup *** This bug has been marked as a duplicate of 138892 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Kai -- Why do you think this is a dup of bug 138892? That bug deals explicitly with the case where there is more than one form on a page, and there is only one form on the page in this bug.
ooops...
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Thanks, Kai. Adding 4xp keyword since I don't see this problem with NS4, and dataloss keyword because of...well...the dataloss.
Keywords: 4xp, dataloss
I have narrowed the bug down to the following culprit: a misplaced form tag coupled with a misplaced hidden input tag. The HTML source currently has the following lines (excerpt only): ...<tr> <form METHOD="POST" ACTION="/cgi/indmed/imd1"> <input type="hidden" name="cert" value="imd1"> <input type="hidden" name="xx" value="xx"> <input type="hidden" name="inm" value="Applicant"> <input type="hidden" name="snm" value="Spouse"> <input type="hidden" name="ssx" value="1"> <input type="hidden" name="pw" value="XXXXXX"> <td width="65%">... Clearly nothing belongs between a tr and td tag; they should have put the stuff somewhere else. But Moz should probably handle this case better. Bug form value restoration worked fine when I made either (or both) of the following changes: a) move the <input type="hidden">elements from in between <form> and <td> (<tr><form><input type="hidden"><td>) to inside the <td> (<tr><form><td><input type="hidden">...</td>) b) move the <form> element from in between <tr> and <td> (<tr><form>...<td>) to before the table (<body>...<form><table><tr>...) or to inside the <td> (<tr><td><form>...). As far as I can tell, this effect is observable _only_ when the misplaced input element's type="hidden" (tried it with some other input types, form value restoration worked fine). I move that the summary of this bug be changed to something like: "misplaced form element and hidden input element(s) break form value restoration" There is also some tech evang here: the HTML on the page is maximally convoluted garbage. But presumably Mozilla ought to be able to recover (right?). In case anyone is interested, IE 6 on Win 98 does form value restoration fine (and someone said NS4 also does). Definitely change OS: Linux->All (I'm seeing this with Win 98 nightly build 2002060408). And probably send it over to component Form Manager (and jkeiser).
Hi David, Thanks for the excellent research! I have changed the summary per your recommendation. I'm not sure if this should go to "Form Submission" or "HTML Form Controls".
Summary: Form contents are lost when pressing back → Misplaced form element and hidden input element(s) break form value restoration when pressing Back
Actually, the best place might be "History:Session", since related bugs live in that component (Bug 46845, Bug 138892). However, Bug 133946 is very similar (something about the mark-up breaking the form value restoration) and that one is under "Form Submission" (which doesn't make any sense to me). I still think this bug to go under "History:Session". Someone there would send it elsewhere if it's the wrong component.
-> Form submission
Assignee: Matti → alexsavulov
Component: Browser-General → Form Submission
QA Contact: imajes-qa → vladimire
*** This bug has been marked as a duplicate of 158258 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → DUPLICATE
Alexandru -- Hrm. Bug 158258 is the same as this bug at the end, but it starts of as a completely different bug, dealing with the case where the user closes Mozilla or it crashes. Please re-read the first paragraph of bug 158258, and see if you still think that this bug is the same as that one. It looks to me like they're completely different. It seems to me that your testcase from bug 158258 should be brought over here, and that bug 158258 should be allowed to revert back to its original purpose. If you still think this is a dup, feel free to re-dup it, but please update the summary of bug 158258 to reflect that it has changed from it's original purpose; otherwise nobody will be able to find it.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
yes i was about to do that but i had some troubles at work with the corporate network so i couldn't take care of this. could you please do that? thx!
Attached file Alexandru Savulov's testcase (obsolete) —
Here's Alexandru Savulov's testcase from bug 15828.
That attachment is from bug 158258, of course; I mistyped the bug number.
the initial testcase without <tbody> and so on. it reveals the value wandering be cause of the unnamed inputs too.
Attachment #95317 - Attachment is obsolete: true
John, i reassign this to you cause i have no chance getting to it. i set a milestone and priority to have them there, however they might be inaccurate. this bug seems to me worth of a nomination.
Assignee: alexsavulov → jkeiser
Priority: -- → P2
Target Milestone: --- → mozilla1.2beta
Hmm, strange. When this page is loaded the controls have these keys: hidden: input>garbage>8>>0>0-C select: select>month>>0>1-C text: input>>14>>0>2-C But when it is unloaded these are the only keys we try to restore with: select: select>month>>0>0-C text input: input>>14>>0>1-C It is as though the hidden input was removed from the document and the form early and that screwed up the index-in-the-form (the number before the C) for the other controls. It is also troubling that the input is not saved. This is a relatively non-big-deal, but I'll look into it. It should get fixed when I redo layout history and get rid of content IDs--whenever that happens.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: P2 → --
Target Milestone: mozilla1.2beta → ---
*** Bug 163305 has been marked as a duplicate of this bug. ***
OS: Linux → All
Priority: -- → P4
Depends on: 139568, 147322, 166636
Bulk moving P1-P5 un-milestoned bugs to future.
Target Milestone: --- → Future
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: normal → critical
*** Bug 181455 has been marked as a duplicate of this bug. ***
Keywords: 4xp → testcase
*** Bug 164336 has been marked as a duplicate of this bug. ***
OK, it seems we have another serious flaw in form state restoration algorithm. What is happening here is, we are saving the inputs as SetDocument(nsnull) is called on them. The thing is, we *also* happen to remove the element from the form. This shifts the indices for everything. There is a hack to deal with this in nsGenericHTMLContainerFormElement::SetDocument that checks to see if the form's document is null. This is true for all elements that are physically contained in the form since the form's document will be nulled out before its children. Basically, we need to find a different time to save the form elements, probably a pass through a listener that is called before document destruction.
Severity: critical → major
Priority: P4 → P3
*** Bug 197296 has been marked as a duplicate of this bug. ***
*** Bug 191235 has been marked as a duplicate of this bug. ***
*** Bug 210214 has been marked as a duplicate of this bug. ***
*** Bug 219564 has been marked as a duplicate of this bug. ***
*** Bug 171972 has been marked as a duplicate of this bug. ***
*** Bug 231813 has been marked as a duplicate of this bug. ***
Any activity on this bug? I still get bitten by it at times.
Blocks: 311507
Blocks: 372887
Assignee: john → nobody
Priority: P3 → --
QA Contact: vladimire → form-submission
Target Milestone: Future → ---
I tried some testcases of duplicates (like Bug 197296, Bug 219564) but I can't reproduce the problem, only in old builds.
This is a mass change. Every comment has "assigned-to-new" in it. I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
Component: HTML: Form Submission → DOM: Core & HTML

Marking this as Resolved > Worksforme since the issue is not occurring anymore using Release 93.0, Beta 94.0b2 and latest Nightly 95.0a1 (2021-10-07) on Windows 10 and Ubuntu 20.04 and MacOS 11.6.
If anyone else is able to reproduce it please re-open the issue or file a new one.

Status: NEW → RESOLVED
Closed: 22 years ago → 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: