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.
Joomla! has a bug for this in our tracker as well: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=4711 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:220.127.116.11) Gecko/2007091417 Firefox/18.104.22.168 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/2007073113 Firefox/126.96.36.199 (Ubuntu-feisty)
This is still an issue using the following: http://www.marcreichelt.de/misc/firefox/bug394782/ 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?
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: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-10-31+04&maxdate=2004-11-01+10&cvsroot=%2Fcvsroot 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: http://www.ryancramer.com/journal/entries/radio_buttons_firefox/. Also, he has a very simple test case here: http://www.ryancramer.com/projects/asmselect/examples/autocomplete.html 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.
8 years ago
(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. -Boris Boris: the workarounds would confirm the issue is in form autocomplete, as you suggested in comment #8. Vlad
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: http://www.ryancramer.com/journal/entries/radio_buttons_firefox/ 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: http://core.trac.wordpress.org/ticket/17051
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 www.ryancramer.com, 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 http://www.ryancramer.com/projects/asmselect/examples/autocomplete.html : 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 ryancramer.com 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.