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
Both buttons checked in step 3 _and_ step 6 are checked (and both will be
successful on a second submit).
The button checked in step 3 gets unchecked.
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
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
The URL is mainly a testcase for bug 46338.
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).
Nom. nsbeta3. Clear data loss scenario (or data corruption depending on server
Eric, this looks similar another one I cc'ed you earlier. Any ideas? Thanks,
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.)
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
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.
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.
*** Bug 45396 has been marked as a duplicate of this bug. ***
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.
Created attachment 13773 [details] [diff] [review]
fix in nsGfxRadioControlFrame.cpp
Looks like this patch fixes the bug!
Fix checked in. To verify, look at the above test case and repeat the above
five steps. Only one radio button should be checked!
VERIFIED Fixed with 200008311 builds