Bug 5879

Summary: REGRESSION: Buttons go into pushed state when moused over when text field has focus
Product: WebKit Reporter: Rosyna <webkit-bugs>
Component: FormsAssignee: Dave Hyatt <hyatt>
Status: RESOLVED FIXED    
Severity: Normal CC: mitz
Priority: P1    
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
URL: http://www.unsanity.org/archives/000439.php
Attachments:
Description Flags
testcase: click in the textview
none
Initialize m_inActiveChain to false eric: review+

Description Rosyna 2005-11-29 13:23:04 PST
Go to http://www.unsanity.org/archives/000439.php and click inside the comments text field. While the 
view has keyboard focus, mouse over the preview or post buttons. They will go into the pushed state. This 
is not 100% reproducible which makes it even more annoying.
Comment 1 Rosyna 2005-11-29 13:23:57 PST
Created attachment 4854 [details]
testcase: click in the textview
Comment 2 mitz 2005-11-29 13:30:01 PST
Confirmed on TOT. Due to randomness of the phenomenon, I couldn't reproduce it with the attached 
testcase, but I'm actually seeing it right now as I'm typing in the comments text area if I move the mouse 
over the Commit button. This regression is as old as the customizable buttons, IIRC.
Comment 3 mitz 2005-11-29 15:29:56 PST
I don't know this code, but from looking around with gdb, the problem might be that the KHTMLView's d-
>mousePressed stays at true after you click in an AppKit widget such as a text area. If a few other 
parameters are lined up, an :active chain gets frozen, consisting of a bunch of objects, which may include 
buttons and also normal text links. Those objects will change to/from their :active state as the mouse 
passes over them, like what happens when you mousedown in an object and start dragging around.
Comment 4 mitz 2005-11-29 15:44:30 PST
More likely, the fact that (d->mousePressed == true) throughout is normal, and the problem is those 
stray objects which thing that think that they are in the active chain. I don't see NodeImpl's m_hovered 
being initialized to false, and that's a bad sign.
Comment 5 mitz 2005-11-29 15:45:25 PST
s/m_hovered/m_inActiveChain/
Sorry for the spam.
Comment 6 mitz 2005-11-29 16:13:01 PST
Created attachment 4856 [details]
Initialize m_inActiveChain to false

Should have noticed this when bug 4221 was fixed :-)
Comment 7 Eric Seidel (no email) 2005-11-29 16:23:26 PST
Comment on attachment 4856 [details]
Initialize m_inActiveChain to false

I've seen this happen too. It would be even better if we could have a dom test
to prevent this from regressing again.
Comment 8 Darin Adler 2005-11-29 17:50:21 PST
I can't believe this! Beth and I spotted this uninitialized variable *today* while fixing another bug.