In a web page I'm working on, I use "CHECKED" to indicate that a radio button in a radio group is checked by default. Mozilla renders the radio group with no default button checked, however. I've looked at my code and it doesn't appear buggy. It also renders in IE. I'll attach the page (It's dynamically generated).

This is really weird. When I view the attachment I just attached, it renders correctly. When I open the HTML document I saved, it renders correctly. But when I run the perl script that generates thie document, it doesn't render correctly. However, when I pipe the output from the perl script to a file and then open that file, it also renders correctly. I'll look into this further.

If I have the authority, I will definitely mark this bug CONFIRMED. I have experienced this many many times and I agree to the reporter claim that saved html file has no problem. Only dynamic webpage (.asp,.jsp..etc.) will cause this problem.

First, this is _so_ the wrong component. Second, Jeremy, could you possibly post a url to a functioning testcase demonstrating this bug? Hard to fix it otherwise... Also, what build are you using?

I've been trying, but I haven't been able to duplicate it consistently. It's not as simple as copying and pasting the HTML into a CGI script (for example, the perl script at "http://web.utk.edu/cgi-bin/cgiwrap/~jtbrown/mozilla_bug.pl", which is just one big print statement, seems to handled the CHECKED tag fine). All of the scripts that mis-rendered for me before are on my previous employer's servers, so I don't know that I can get access to them for test cases (but I will try). And, at the time I reported this bug I was using Mozilla 1.0. Will post again as soon as I can consistently duplicate this.

I also experienced this recently..but really hard to reproduce but I am quite sure there is a bug..

A page where it fails and the build it fails on would be nice. Try on a recent build, please: a major set of radio button fixes went in after 1.0.

An example is at ... http://www.simong.net/mozCacheBug/ 'disabled' follows fine but 'checked' dosn't. See the source where iv'e even tried to disable caching.

That's not this bug but rather bug 46845

I've never posted here before; I hope this is the right way to do it. I have witnessed this bug as well. On a Cold Fusion-generated page the radio button is not checked even though "checked" clearly exists when I view source. The button is checked when viewed in IE. When I save the page as HTML and load that, the button is checked. Totally bizarre that it is not checked when generated dynamically by CF, but is checked when saved as static HTML. I have noticed that this behavior tends to affect controls with underscores in the NAME attribute more frequently, but this is inconsistent as well. I'm sorry I can't provide a link to an example, but all the applications I've witnessed this behavior on are behind firewalls. I'm using Phoenix 0.5 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021210 Phoenix/0.5).

I think I just hit this while posting a comment to bug 196124. None of the leave unconfirmed / resolve / reasign radio buttons were checked. I can't reproduce it at the moment - I'll keep an eye on those radio buttons though.

I tried it on the most recent Mozilla build (1.4 Alpha (16th April 2003)) and the bug does not exist on the test batches I had used. Simon Pang

Sorry, I just discovered, the bug is still present, sorry. Simon Pang

Simon, that's great! What page were you on, and how did you get it to happen?

I used the test site, created by comment #8 (Simon G) and the bug is still seen to be there. I tested on another famous web browser and no bug there.

Tested using Mozilla build 1.4b (Gecko build: 2003041) on the Microsoft Windows XP (NT version 5.1, build: 2600) (service pack 1) platform and with test batches, the bug is not apparant. I tired opening several HTML pages using Mozilla with the chekced radio buttons but the feature worked as expected, bug was not present. Simon Pang Footnotes: The following HTML pages were used to test this bug (you may have to copy and paste the URLs into the address bar as the hyperlinks are incomplete): 1) http://www.echoecho.com/htmlforms10.htm 2) http://www.htmlclinic.com/forms.php

The test from comment 8 has nothing to do with this bug, I repeat.... See comment 9.

Comment # 17 is INCORRECT! Bug #46845 is about Manual Reload of form pages. THIS bug ( bug # 159617) is about the "checked" value of an input button. :) Simon G

Bug #46845 is about reload of page in general. Manual or programmatic. Please stop making comments irrelevant to this bug in this bug.

The test from comment 8 has EVERYTHING to do with this bug, I repeat.... See comment 8

I saw comment 8. The problem with that testcase is that the page is reloaded (via a refresh header). Then bug 46845, which has to do with pages being reloaded, kicks in. THIS bug was about a page that's just loaded showing a problem, with no reloading involved. That is, until you started posting irrelevant testcases and arguing that they are relevant....

Re comment # 21 My friend, Ahh but the reloaded page is NOT static, so it wouldn't be fair to say that the SAME page is being reloaded, as in bug # 46845. It would be more FAIR to say that it IS THIS BUG (bug #159617), "Mozilla renders the radio group with no default button checked". The argument continues !! :)

THIS BUG HAS NOTHING TO DO WITH RELOADING. OK? Bug 46845 covers precisely the case when a reload returns a different page from the server; if it returns the same page, there is clearly no problem. Have you even read it? This is not a bulletin board to argue in, it's a bug database, ok? Please respond in personal mail, if at all.

When radio buttons are required fields on the page (through javascript validation), even though one of buttons is checked, the browser still says the radio button is not checked. The same javascript code works fine in IE or Netscape.

Rajiv, that sounds like a different bug. Please file it, cc me, and attach a testcase. I'm marking this bug worksforme, since the original problem is not visible and there has been no response from the reporter.