134560 - [PATCH]Stray(random) radio (or checkbox) button appears at top of page

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Brian Ryner (not reading)]

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.

Comment 1

[Andrew Schultz]

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...  

Comment 2

[Vadim Berezniker]

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

Comment 3

[Igor Furlan]

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

Comment 4

[Brian Ryner (not reading)]

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

Comment 5

[Vadim Berezniker]

Attachment: screenshot

Comment 6

[James Cox]

yep, i'm getting this too.

Comment 7

[John Keiser (jkeiser)]

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.

Comment 8

[Vadim Berezniker]

<input type="radio" checked="checked">

produces two radio-buttons
if you remove checked attribute, it no longer happens

Comment 9

[Vadim Berezniker]

Attachment: testcase

this testcase shows two radio buttons instead of one

Comment 10

[Andrew Lin]

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...

Comment 11

[Vadim Berezniker]

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.

Comment 12

[Mike Pinkerton (not reading bugmail)]

yeah, seeing this on mac as well. doh!

Comment 13

[Asa Dotzler [:asa]]

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

Comment 14

[Vadim Berezniker]

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

Comment 15

[scottputterman]

Adding nsbeta1+ and [adt1]

Comment 16

[John Keiser (jkeiser)]

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.

Comment 17

[John Keiser (jkeiser)]

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

Comment 18

[John Keiser (jkeiser)]

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

Comment 19

[John Keiser (jkeiser)]

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.

Comment 20

[Olav Vitters]

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

Comment 21

[Marc Boullet]

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

Comment 22

[Olav Vitters]

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

Comment 23

[John Keiser (jkeiser)]

Attachment: Patch

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

Comment 24

[John Keiser (jkeiser)]

Attachment: Patch

The actual patch.

Comment 25

[John Keiser (jkeiser)]

Attachment: Patch v2

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.

Comment 26

[John Keiser (jkeiser)]

Attachment: Patch v2

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

Comment 27

[Brian Ryner (not reading)]

Comment on attachment 77365 [details] [diff] [review]
Patch v2

r=bryner

Comment 28

[Johnny Stenback (:jst)]

Comment on attachment 77365 [details] [diff] [review]
Patch v2

sr=jst

Comment 29

[Jaime Rodriguez, Jr.]

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

Comment 30

[Asa Dotzler [:asa]]

Comment on attachment 77365 [details] [diff] [review]
Patch v2

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 31

[Vadim Berezniker]

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

Comment 32

[Vadim Berezniker]

chaing summary to make this bug easier to find

Comment 33

[Vadim Berezniker]

gah. hit enter key by accident. fixing

Comment 34

[Vadim Berezniker]

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

Comment 35

[John Keiser (jkeiser)]

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

Comment 36

[Matthias Versen [:Matti]]

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

Comment 37

[Olav Vitters]

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

Comment 38

[Vadim Berezniker]

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

Comment 39

[Bradley Baetz (:bbaetz)]

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

Comment 40

[Terri Preston]

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