Go to the URL listed, note the stray radio button appearing just above the Bug# / Platform / Reporter row of form controls. This happens when viewing any bugzilla bug with a trunk build today, and happens whether XBL form controls are enabled or not.

I have been seeing this for a few days or more, but never reproducibly and not so much recently (currently with build 20020329). One time I got 2 radio buttons. I have never seen it happen on the initial loading of any page, but sometimes it show up after going "back" or reloading. Also, if I click one of the radio buttons, the page scrolls down...

build time: 2002033119 on linux i see the radio box on every single page of bugzilla it's right below the horizontal line, all the way to the left of the page. also once I saw a listbox in the middle of the page but w/o text which could be related

I am ____not_____ able to reproduce it on Linux WFM !! system RH6.2 Linux kernel 2.2.14-5 screen resolution 1600x1200 Mozilla 0.9.9 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020310

Note that the bug was not reported against 0.9.9, it was reported against current trunk builds.

yep, i'm getting this too.

Hmm, given Andrew's comments (and my past experience) perhaps this is likely some radio restore timing thing that was (possibly) created in bug 108308 and was exposed more extremely with bug 108309. I'll look at it in the morning; meantime, reduced testcases will help tremendously.

<input type="radio" checked="checked"> produces two radio-buttons if you remove checked attribute, it no longer happens

this testcase shows two radio buttons instead of one

I don't know if this has been reported somewhere else, but in case it's relevant: Open any bug with no cc's (the most recent bug of the day tends to work) and notice that the CC: list is not only empty, but completely missing...

if you look at the HTML, bugzilla does not write a listbox at all if there are no CCs. Nothing to do with this bug.

yeah, seeing this on mac as well. doh!

can't ship this in a Mozilla 1.0 Release Candidate. adding mozilla1.0+

*** Bug 134744 has been marked as a duplicate of this bug. ***

Adding nsbeta1+ and [adt1]

checked="checked" is not the problem. When you change that testcase to use just checked, it exhibits the problem. The problem there is no body element.

Turns out not having a form and being checked is the trigger.

And it's not just radios, it's checkboxes. I've narrowed it down to the call to ContentStatesChanged().

All right. The problem is this: http://lxr.mozilla.org/seamonkey/source/layout/html/style/src/nsCSSFrameConstructor.cpp#10215 This creates an extra frame when nsHTMLInputElement::DoneCreatingElement() is called. This ends up setting checked, which calls ContentStatesChanged(). This will create a frame that I believe was unintended. The reason this is happening now is, RestoreState occurs in DoneCreatingElement(). What I do not know is why the second frame still gets created. Something about this frame must be bogus--we must be creating it at a bad time. The reason I know this is the source of the extra frame is, commenting out ContentStatesChanged() fixes it. We have several avenues of attack now: 1. Call something other than ContentStatesChanged() to register the change to :checked. 2. Change ContentStatesChanged() to not create a frame or make the frame state proper. 3. Don't call ContentStatesChanged() unless XBL form controls is on or the primary frame is already created. #3 is easiest. #2 (make the frame state proper) is probably better, but I don't know what's causing the problem. If we *don't* fix that, though, other selectors are going to have problems and have #3 happen. Perhaps #3 now, and #2 when we figure out wassup.

*** Bug 134842 has been marked as a duplicate of this bug. ***

*** Bug 134852 has been marked as a duplicate of this bug. ***

*** Bug 134932 has been marked as a duplicate of this bug. ***

This patch fixes the problem for ordinary form controls, but *not* for XBLFC. I am continuing to investigate the underlying problem.

The actual patch.

This is the patch I want to put in right now. According to hyatt, calling ContentStatesChanged() when there is no frame is a Bad Thing and causes crashes on occasion as well as behavior like this. This must be stopped, but people might stomp on API changes for RC1, so we offer up the Workaround.

Once again, here is the patch I meant to post.

Comment on attachment 77365 [details] [diff] [review] Patch v2 r=bryner

Comment on attachment 77365 [details] [diff] [review] Patch v2 sr=jst

adt1.0.0+ (on ADT's behalf) for checkin into 1.0.

Comment on attachment 77365 [details] [diff] [review] Patch v2 a=asa (on behalf of drivers) for checkin to the 1.0 trunk

*** Bug 135139 has been marked as a duplicate of this bug. ***

chaing summary to make this bug easier to find

gah. hit enter key by accident. fixing

*** Bug 135179 has been marked as a duplicate of this bug. ***

Checked in last night. Should appear in today's builds.

*** Bug 135218 has been marked as a duplicate of this bug. ***

*** Bug 135227 has been marked as a duplicate of this bug. ***

*** Bug 135356 has been marked as a duplicate of this bug. ***

*** Bug 135603 has been marked as a duplicate of this bug. ***

Verified linux trunk (2002042208) branch (2002042210) Win 2k trunk(2002042209 ) branch (2002042206) and Mac OS X trunk (2002042203) branch (2002042205)