Bug 5879 - REGRESSION: Buttons go into pushed state when moused over when text field has focus
Summary: REGRESSION: Buttons go into pushed state when moused over when text field has...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P1 Normal
Assignee: Dave Hyatt
URL: http://www.unsanity.org/archives/0004...
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-29 13:23 PST by Rosyna
Modified: 2005-11-29 17:50 PST (History)
1 user (show)

See Also:


Attachments
testcase: click in the textview (334 bytes, text/html)
2005-11-29 13:23 PST, Rosyna
no flags Details
Initialize m_inActiveChain to false (1.37 KB, patch)
2005-11-29 16:13 PST, mitz
eric: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.