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.
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
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
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
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.
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.
Assignee: radha → pollmann
Status: ASSIGNED → NEW
Component: History → HTML Form Controls
Looks like this patch fixes the bug!
OS: Windows NT → All
Hardware: PC → All
Whiteboard: [nsbeta3+] → [nsbeta3+] fix in hand
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: 19 years ago
Resolution: --- → FIXED
VERIFIED Fixed with 200008311 builds
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.