137247 - grippy not responding to :hover in sidebar and toolbars

Status: RESOLVED DUPLICATE of bug 137067

(Core :: CSS Parsing and Computation, defect)

Description

[J Vender]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020412
BuildID:    2002041203

When the mouse is placed over the resize buttons [I don't know what they are
properly called so I'll call them the splitter buttons on the window dividers
(for example, the divider between the sidebar and the main browser window) which
turn purple when the mouse is moved over them] they don't change color until the
mouse is clicked and then they change color and stay that way.

Reproducible: Always
Steps to Reproduce:
1.Open either the browser or mailnews interface. (This is a problem with both)
2.Move mouse over the window splitter buttons.
3.Click the mouse button.

Actual Results:  The window splitter buttons don't respond to the mouseover
event by changing color as they should. They change color only after the mouse
button is clicked and then stay in that new color state even after the mouse if
moved off the button. The color change appears to be responding to an "onClick"
event rather than an "onMouseOver" event.

Expected Results:  The button color change should occur as a mouseover event,
changing color as the mouse pointer is moved over the button, and then should
change back to the original color state as the mouse pointer is moved off the
button. The color change should not be related to the click event.

The widgets/buttons work correctly in the latest milestone release 0.9.9

Comment 1

[John Morrison]

(Changing summary from "color change on mouseover of window resize buttons not 
working properly" to the more technical description).

This also shows up in the toolbar grippy's, which don't change state on :hover 
either (although the personal toolbar's grippy will respond if you move the 
mouse up from directly below the grippy, but not if you move laterally over the 
grippy).

So, this is fallout from the landing of dbaron's changes for bug 5693 ':hover 
should be hierarchical'. I've backed out those changes (checkin at 20:48/9 
4/10), and the grippy's begin to behave correctly to :hover.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

My guess is that my changes tweaked an existing bug in StyleSetImpl::WalkRules
and the nsIStyleRuleSupplier interface -- that the "break out of the walking"
case doesn't work.  HasStateDependentStyle depends on that working, and now
HasStateDependentStyle is a bit more sensitive because of the optimizations that
make it depend only on the exact state that changed.

I'll try this now and see if it fixes the problem.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Duping to the earliest of the bugs filed on this problem (based on bug 5693
comment 196).

*** This bug has been marked as a duplicate of 137067 ***

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I take that back.  The patches there fix only the back button and the dialog
buttons, not the grippy.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Oh.  Hmm.  So there are a bunch of selectors that look like this in the modern
theme:

splitter.css:
splitter[collapse="before"]:hover:active > grippy {
splitter[collapse="after"]:hover:active > grippy {
splitter[collapse="before"][orient="vertical"]:hover:active > grippy {
splitter[collapse="after"][orient="vertical"]:hover:active > grippy {
splitter[collapse="before"][state="collapsed"]:hover:active > grippy {
splitter[collapse="after"][state="collapsed"]:hover:active > grippy {
splitter[collapse="before"][state="collapsed"][orient="vertical"]:hover:active >
grippy {
splitter[collapse="after"][state="collapsed"][orient="vertical"]:hover:active >
grippy {

toolbar.css:
toolbargrippy[tbgrippy-collapsed="true"]:hover:active > .toolbargrippy-arrow {


We've never properly supported dynamic style changes on such rules -- doing so
would probably mean removing the HasStateDependentStyle optimization completely.
 Then the question would be what to replace it with:  see bug 5693 comment 161
and bug 75559.  I'm not sure if we even have a bug on the general problem.

My patch in bug 5693 probably triggered this bug because I made
HasStateDependentStyle more sensitive, and presumably the elements in question
have other rules that respond to event state changes.

This could probably be worked around by adding empty rules (or rules with
something silly in them, since we might optimize empty rules away) to trigger
style reresolution.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I filed the real bug underlying this problem as bug 137395.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This "general problem" that I thought we had was my imagination.  We build
mStateSelectors in nsCSSStyleSheet.cpp to avoid it.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The comments above led me to add a bunch of comments (and a performance fix to
IsStateSelector) to my patch in bug 128743.

I still have no idea what's wrong here.

Comment 9

[Robert Kaiser]

reporter:
all problems like this went away for me with the fix to bug 137067 - is this
true for you as well?

If this is the case, you should mark this as a dupe of 137067 (again). I really
think it was the same problem.

Comment 10

[John Morrison]

hmm, yes. dbaron: the grippy's on both the sidebar and on the toolbars are 
showing the correct response to :hover in the 2002-04-16-17-WIN_GMAKE build
on win2k.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Ah, right.  I get it now.  There are no :hover effects in Modern (I compared to
RC1, which doesn't have bug 5693 fixed in it), but I thought there were. 
Classic works fine.  So this is almost definitely a duplicate as I marked it
originally.

*** This bug has been marked as a duplicate of 137067 ***