Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 50143 - going back in session history can lead to multiple checked radio buttons in a form
: going back in session history can lead to multiple checked radio buttons in a...
[nsbeta3+] fix in hand
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: Trunk
: All All
: P1 normal (vote)
: ---
Assigned To: Eric Pollmann
: Claudius Gayle
: Jet Villegas (:jet)
: 45396 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2000-08-24 06:43 PDT by Andreas M. "Clarence" Schneider
Modified: 2000-12-15 18:37 PST (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

fix in nsGfxRadioControlFrame.cpp (756 bytes, patch)
2000-08-30 17:46 PDT, Eric Pollmann
no flags Details | Diff | Splinter Review

Description Andreas M. "Clarence" Schneider 2000-08-24 06:43:10 PDT
Steps to reproduce:
1. Go to
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 ), 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 John Morrison 2000-08-24 12:59:34 PDT
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). 
Comment 2 John Morrison 2000-08-24 13:00:25 PDT
Nom. nsbeta3. Clear data loss scenario (or data corruption depending on server 
Comment 3 Radha on family leave (not reading bugmail) 2000-08-29 11:59:07 PDT
Eric, this looks similar another one I cc'ed you earlier. Any ideas? Thanks,
Comment 4 verah (gone) 2000-08-29 13:36:10 PDT
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.)
Comment 5 Andreas M. "Clarence" Schneider 2000-08-30 13:30:32 PDT
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
Comment 6 Radha on family leave (not reading bugmail) 2000-08-30 14:07:20 PDT
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.
Comment 7 Eric Pollmann 2000-08-30 16:39:41 PDT
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...
Comment 8 David Baron :dbaron: ⌚️UTC-7 (busy until November 7) 2000-08-30 16:48:57 PDT
See bug 45396.
Comment 9 Eric Pollmann 2000-08-30 17:38:53 PDT
*** Bug 45396 has been marked as a duplicate of this bug. ***
Comment 10 Eric Pollmann 2000-08-30 17:43:30 PDT
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.
Comment 11 Eric Pollmann 2000-08-30 17:46:43 PDT
Created attachment 13773 [details] [diff] [review]
fix in nsGfxRadioControlFrame.cpp
Comment 12 Eric Pollmann 2000-08-30 17:47:19 PDT
Looks like this patch fixes the bug!
Comment 13 Eric Pollmann 2000-08-30 18:00:20 PDT
Fix checked in.  To verify, look at the above test case and repeat the above
five steps.  Only one radio button should be checked!
Comment 14 Claudius Gayle 2000-08-31 18:49:11 PDT
VERIFIED Fixed with 200008311 builds

Note You need to log in before you can comment on or make changes to this bug.