Closed Bug 394782 Opened 15 years ago Closed 6 years ago

Radio buttons change on refresh


(Core :: Layout: Form Controls, defect)

Not set





(Reporter: mcreichelt, Unassigned)




(Keywords: regression, Whiteboard: DUPEME)


(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv: Gecko/20070713 Firefox/
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv: Gecko/20070713 Firefox/

When loading, the yes/no radio buttons on show the correct status (the "no" radio buttons are selected).
After reloading with F5, the radio buttons change their state (the JavaScript on this site leaves the radio buttons untouched).

Reproducible: Always

Steps to Reproduce:
1. Start Firefox.
2. Load into your browser.
3. Press F5 and notice that the radio buttons have changed.
Actual Results:  
The radio buttons change their state.

Expected Results:  
The radio buttons should not change their state.

The bug also happens on Windows.
OS: Linux → All
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007090222 Minefield/3.0a8pre

Yeah, I see this too. With the Flashblock extension installed I don't see the problem.
It is a regression somewhere in the last quarter of 2004.
Keywords: regression
(In reply to comment #0)
I now moved the experimental site to (for better testing purpose) and removed lot of JavaScript code there.
The error seems to occur if a flash object is dynamically showed using Node.innerHTML (see line #47 on

Can somebody see what the problem here is?
Joomla! has a bug for this in our tracker as well:

The issue cannot be replicated in any other browser except for Firefox. It appears to be related to an issue with radio button. Whilst I wasn't able to produce some simple sample code to get the refresh to change the selected button, I was able to generate some simple sample code that shows that the radio button state isn't being set properly on a page refresh.

Steps to reproduce:
1) Create a simple HTML document with a set of radio buttons without any marked as checked. The Joomla! tracker has some sample code.
2) Load up in Firefox. The correct state should be shown.
3) Update the text file and change/set the checked value and also update some text on the page
4) Refresh in the same tab/window of Firefox. The radio button won't change state however the text will update.
5) Open a new window/tab and load the page. The page renders appropriately.

Tested platforms:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-GB; rv: Gecko/2007091417 Firefox/
Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2007073113 Firefox/ (Ubuntu-feisty)
Severity: normal → major
This is still an issue using the following:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3
yes, and also still an issue using the following builds:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b5pre) Gecko/20090427 SeaMonkey/2.0b1pre
Mozilla/5.0 (Windows; U; WindowsNT 5.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4

Confirming & reassigning - maybe someone who knows the issue better can take a look at it.

Marc: Do you know when exactly the regression happened?
Component: General → Layout: Form Controls
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → layout.form-controls
Hardware: x86 → All
Martin: I don't know when this regression happened exactly, and in the moment I am unable to test this. I will set up Ubuntu 9.04 in VirtualBox and will test some old nightly builds if I get the time to.
This regressed between 2004-10-31-07 and 2004-11-01-07.  Bonsai range:

If the radios are being added via script, this is probably a regression from bug 204784 and almost certainly a dup of the bug on form state restoration being confused on reload if the button order at page unload doesn't match that on page parse.
Ryan Cramer discusses the issue here:  Also, he has a very simple test case here:

I've been bit by this issue several times already.
Instead of refreshing the page with F5 or Ctr+R insert the cursor in the address bar, hit the return key and the radio buttons will no longer cycle. Same result when using Shift+Ctrl+R. This might give a hint to where the bug is living.
Whiteboard: DUPEME
(In reply to comment #11)

Vlad, have you read the bug?  In particular comment 8?

Loading via url bar or forced reload does not perform form state 
restoration, so obviously a bug in form state restoration wouldn't be 
observable that way.


the workarounds would confirm the issue is in form autocomplete, as you suggested in comment #8.
I can confirm this is still an issue. Running 3.6.8 on Mac OS X 10.6.4. I'll admit that I am a little shocked to see that this issue is nearly three years old and still no resolution!

For anyone that needs help developing around this bug, please read:

Granted, the fix isn't perfect, but if necessary it will give you an option.
This is still a problem in Firefox 4.0b13pre.
Seems to have popped up in WordPress recently:
Still a problem in 4.0.1.
Confirmed, still a problem in 4.0.1 on Mac OS X 10.6.7
@Mark Craver: per your fix from, I was able to prevent the problem by just putting autocomplete="off" on the radio buttons themselves, this way you can still get autocomplete on the other fields
Just revisited this bug and noticed that I can't reproduce in the latest version of FF.  I guess it was fixed somewhere along the way.
hi dave,

testing : the error shows up with firefox 14.0.1 .
My mistake.  I do still see the problem if the initially selected radio button is changed.  (I'm not sure if changing the selected button was necessary to reproduce the problem in the past.  I don't think it was.)
I just checked and I can reproduce this on Firefox 16 as well. I think you need to select a radio button the first time you go to the page but once you've done that once it disappears.

Roughly steps:
1) Go to example
2) Refresh the page a few times; this didn't appear to change the selected radio button
3) Click on the second radio button
4) Refresh the page again

At this point the radio button should change which item is selected progressively each refresh.
This issue is not present in Mozilla/5.0 (Windows NT 6.3; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0

I will close this bug as WFM. Please reopen if this issue persists.
Closed: 6 years ago
Resolution: --- → WORKSFORME

Firefox 72.0.1 (64-bit) on OSX Catalina and the bug is still present.

This is an example page where it can be reproduced:

Important to note that, neither the fix that this page proposes works...

(In reply to stathis from comment #24)

Firefox 72.0.1 (64-bit) on OSX Catalina and the bug is still present.

This is an example page where it can be reproduced:

I don't see that on nightly, but mind filing a new bug for that with steps to reproduce? Commenting on a bug closed 4 years ago is not the best way to attract attention to an issue.

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