Closed
Bug 394782
Opened 17 years ago
Closed 8 years ago
Radio buttons change on refresh
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: mcreichelt, Unassigned)
References
()
Details
(Keywords: regression, Whiteboard: DUPEME)
Attachments
(1 file)
832 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 When loading, the yes/no radio buttons on http://www.marcreichelt.de/misc/emff0.5/ 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 http://www.marcreichelt.de/misc/emff0.5/ 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.
Reporter | ||
Updated•17 years ago
|
OS: Linux → All
Comment 1•17 years ago
|
||
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.
Comment 2•17 years ago
|
||
It is a regression somewhere in the last quarter of 2004.
Keywords: regression
Reporter | ||
Updated•17 years ago
|
Reporter | ||
Comment 3•17 years ago
|
||
(In reply to comment #0) I now moved the experimental site to http://www.marcreichelt.de/misc/firefox/bug394782/ (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 http://www.marcreichelt.de/misc/firefox/bug394782/codegenerator.js). Can somebody see what the problem here is?
Comment 4•17 years ago
|
||
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:1.8.1.7) Gecko/2007091417 Firefox/2.0.0.7 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/2007073113 Firefox/2.0.0.6 (Ubuntu-feisty)
Reporter | ||
Updated•17 years ago
|
Severity: normal → major
Comment 5•15 years ago
|
||
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
Comment 6•15 years ago
|
||
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?
Status: UNCONFIRMED → NEW
Component: General → Layout: Form Controls
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → layout.form-controls
Hardware: x86 → All
Reporter | ||
Comment 7•15 years ago
|
||
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.
Comment 8•15 years ago
|
||
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.
Comment 9•15 years ago
|
||
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.
Comment 10•15 years ago
|
||
Comment 11•15 years ago
|
||
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.
Updated•15 years ago
|
Whiteboard: DUPEME
Comment 12•15 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
Comment 13•14 years ago
|
||
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.
Comment 14•13 years ago
|
||
This is still a problem in Firefox 4.0b13pre.
Comment 15•13 years ago
|
||
Seems to have popped up in WordPress recently: http://core.trac.wordpress.org/ticket/17051
Comment 16•13 years ago
|
||
Still a problem in 4.0.1.
Comment 17•13 years ago
|
||
Confirmed, still a problem in 4.0.1 on Mac OS X 10.6.7
Comment 18•13 years ago
|
||
@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
Comment 19•12 years ago
|
||
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.
Comment 20•12 years ago
|
||
hi dave, testing http://www.ryancramer.com/projects/asmselect/examples/autocomplete.html : the error shows up with firefox 14.0.1 .
Comment 21•12 years ago
|
||
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.)
Comment 22•12 years ago
|
||
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.
Comment 23•8 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Comment 24•4 years ago
|
||
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: http://www.ryancramer.com/projects/asmselect/examples/autocomplete.html
Important to note that, neither the fix that this page proposes works...
Comment 25•4 years ago
|
||
(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: http://www.ryancramer.com/projects/asmselect/examples/autocomplete.html
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.
Description
•