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+

Rosyna
Reported 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.
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+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Rosyna
Comment 1 2005-11-29 13:23:57 PST
Created attachment 4854 [details] testcase: click in the textview
mitz
Comment 2 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.
mitz
Comment 3 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.
mitz
Comment 4 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.
mitz
Comment 5 2005-11-29 15:45:25 PST
s/m_hovered/m_inActiveChain/ Sorry for the spam.
mitz
Comment 6 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 :-)
Eric Seidel (no email)
Comment 7 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.
Darin Adler
Comment 8 2005-11-29 17:50:21 PST
I can't believe this! Beth and I spotted this uninitialized variable *today* while fixing another bug.
Note You need to log in before you can comment on or make changes to this bug.