Closed
Bug 137247
Opened 23 years ago
Closed 23 years ago
grippy not responding to :hover in sidebar and toolbars
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 137067
People
(Reporter: jvender, Assigned: dbaron)
Details
(Keywords: regression)
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•23 years ago
|
||
(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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1,
regression
Summary: color change on mouseover of window resize buttons not working properly → grippy not responding to :hover in sidebar and toolbars
Assignee | ||
Comment 2•23 years ago
|
||
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.
Assignee | ||
Comment 3•23 years ago
|
||
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 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 4•23 years ago
|
||
I take that back. The patches there fix only the back button and the dialog
buttons, not the grippy.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee | ||
Comment 5•23 years ago
|
||
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.
Assignee: jaggernaut → dbaron
Status: REOPENED → NEW
Component: XP Toolkit/Widgets → Style System
QA Contact: jrgm → ian
Assignee | ||
Comment 6•23 years ago
|
||
I filed the real bug underlying this problem as bug 137395.
Assignee | ||
Comment 7•23 years ago
|
||
This "general problem" that I thought we had was my imagination. We build
mStateSelectors in nsCSSStyleSheet.cpp to avoid it.
Assignee | ||
Comment 8•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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.
Assignee | ||
Comment 11•23 years ago
|
||
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 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•