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.
Created attachment 4854 [details] testcase: click in the textview
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.
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.
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.
s/m_hovered/m_inActiveChain/ Sorry for the spam.
Created attachment 4856 [details] Initialize m_inActiveChain to false Should have noticed this when bug 4221 was fixed :-)
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.
I can't believe this! Beth and I spotted this uninitialized variable *today* while fixing another bug.