going back in session history can lead to multiple checked radio buttons in a form

VERIFIED FIXED

Status

()

Core
Layout: Form Controls
P1
normal
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: Andreas M. "Clarence" Schneider, Assigned: Eric Pollmann)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+] fix in hand, URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
Steps to reproduce:
1. Go to http://clarence.de/post-test/form.html
2. Type in some text in the first text field
3. Check a radio button which is not the default button
4. Submit form
5. Go back to form
6. Check a different radio button

Actual result:
Both buttons checked in step 3 _and_ step 6 are checked (and both will be
successful on a second submit).

Expected result:
The button checked in step 3 gets unchecked.

Known workaround:
Place cursor in location field and type return to get rid of multiple checked
radio buttons (Reload doesn't do this).

Observed with M17 and 2000082313 on win NT.

Don't know if "XP Toolkit/Widgets: XBL" is the right component for this bug.
It might be a problem with session history.

May be related to bug 45867.

Please note: Steps 2 and 3 are really required to reproduce the bug.

You can reproduce it on a page with only 1 form, too (see
http://clarence.de/post-test/form1.html ), but with 2 forms you can see more
wired behaviour:

If you use the text field in the second form, the bug occures only in the
second form. But if you use the text field in the first form, it occures in
both forms.

The URL is mainly a testcase for bug 46338.

Comment 1

17 years ago
Excellent test case, Clarence! Thanks. This is however something to do with 
session history, I believe. 

(By the way, bug 45867 is about the radio buttons that appear in the UI, which 
are distinct from the radio buttons that appear in web pages). 
Assignee: hyatt → radha
Status: UNCONFIRMED → NEW
Component: XP Toolkit/Widgets: XBL → History
Ever confirmed: true
QA Contact: jrgm → claudius

Updated

17 years ago
Keywords: nsbeta3

Comment 2

17 years ago
Nom. nsbeta3. Clear data loss scenario (or data corruption depending on server 
logic). 
Eric, this looks similar another one I cc'ed you earlier. Any ideas? Thanks,
Status: NEW → ASSIGNED
Target Milestone: --- → M19

Comment 4

17 years ago
Nav triage team: [nsbeta3+], but we're confused: Radha, please look at 41555 and 
see if it is a duplicate of this one. (We're minusing that one because we 
haven't gotten an answer to our "Need Info" in over a week.)
Priority: P3 → P1
Whiteboard: [nsbeta3+]
(Reporter)

Comment 5

17 years ago
It is very unlikely that bug 41555 is a dupe of this.
41555 deals with lost form data after going back. In my testcase form data is
correctly restored. The error occures only if you then check a different radio
button.
when you go back in step 3, the radio button(any form element) will retain the 
value.(it is a feature) i think I already have a bug for the case where reload 
doesn't reset the form element values. If that is fixed, this should be fixed.
(Assignee)

Comment 7

17 years ago
Hey David, do you remember the bug that was just like this one bug on Bugzilla
pages?  I think it was a problem trying to resolve a bug, and somehow two radio
buttons would be checked, and they would concatenate their values on submission.
I searched and could not find the dup.

Here is a way to reliably reproduce this bug on the test case:

1) view test case
2) type in the text input (could not reproduce without this step)
3) select one of the radio buttons
4) Click reload
5) select another radio button

Presto, two radios are selected!  I'll take a quick look to see if I can figure
out what is going on here...
See bug 45396.
(Assignee)

Comment 9

17 years ago
*** Bug 45396 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 10

17 years ago
Thanks for finding the duplicate, David.  I'm really close to a fix for this bug
that involves some minor changes to the RestoreState method of the radio button.

Looks like a bug with the form control frame, and not session history.
Assignee: radha → pollmann
Status: ASSIGNED → NEW
Component: History → HTML Form Controls
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 11

17 years ago
Created attachment 13773 [details] [diff] [review]
fix in nsGfxRadioControlFrame.cpp
(Assignee)

Comment 12

17 years ago
Looks like this patch fixes the bug!
OS: Windows NT → All
Hardware: PC → All
Whiteboard: [nsbeta3+] → [nsbeta3+] fix in hand
(Assignee)

Comment 13

17 years ago
Fix checked in.  To verify, look at the above test case and repeat the above
five steps.  Only one radio button should be checked!
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 14

17 years ago
VERIFIED Fixed with 200008311 builds
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.