Closed Bug 385252 Opened 15 years ago Closed 12 years ago

"grippy" mouseover effects inconsistent in Suiterunner

Categories

(Toolkit :: Themes, defect)

defect
Not set
trivial

Tracking

()

RESOLVED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.1 --- .4-fixed

People

(Reporter: hand_of_fate2000, Assigned: iannbugzilla)

References

Details

(Keywords: polish, verified1.9.1)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070620 SeaMonkey/2.0a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070620 SeaMonkey/2.0a1pre

I'm tasting the latest Suiterunner build (Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/2007062001 SeaMonkey/2.0a1pre).

With the "deafult" theme, the grippies on the toolbars turn off-white when the mouse is over them, but the grippies on the sidebar and mail panels turn purple. The mouse cursor also changes when over the panel grippies but not over the toolbar ones. This is inconsistent.

Reproducible: Always

Steps to Reproduce:
1.Place cursor over "grippies" on toolbar
2.Plece cursor over "grippies" on panels
3.Compare
Actual Results:  
Grippies on panels behave differently to the ones on toolbars

Expected Results:  
All grippies behave consistently
Blocks: 382795
Mnyromyr, any particular reason why you switched away from the old #CCCCFF?
Assignee: general → guifeatures
Status: UNCONFIRMED → NEW
Component: General → XP Apps: GUI Features
Ever confirmed: true
QA Contact: general
Actually, I didn't. :-P
The ThreeDHighlight crept in with Kairo's patch in bug 361159, which we both reviewed. :-(
Maybe a residue of his LCARS theme. ;-)
surely not. I wonder why the default theme that is supposed to use system colors is using a hardcoded #CCCCFF color there that is completely out of place.
IMHO, those should all be system colors, and ThreeDHighlight sounds to me to be the natural choice, given that it's supposed to be the highlight color for 3D UI elements.
(In reply to comment #2)
>Actually, I didn't. :-P
Oops, sorry, I thought you had reimplemented grippies :-[

>The ThreeDHighlight crept in with Kairo's patch in bug 361159, which we both reviewed. :-(
Whomever's patch it was I was afraid of that :-(
(In reply to comment #3)
>ThreeDHighlight sounds to me to be the natural choice,
>given that it's supposed to be the highlight color for 3D UI elements.
But not the hover colour, which is what we're looking for here...
Hmm, so hover is no highlight? And what is the system color for hovered elements?

For someone who might set his system color for normal or disabled UI elements to #CCCCFF (and highlight to, say, white) it surely is a bad choice to hardcode this.
Assignee: guifeatures → nobody
QA Contact: guifeatures
Version: unspecified → Trunk
Component: XP Apps: GUI Features → UI Design
Are we still seeing this? Can we please make our theme consistent here?
Checked latest trunk nightly (Build ID: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090510 SeaMonkey/2.0b1pre)

The hover colour is still off-white for toolbar grippies but purple for panel grippies.
IMHO it should be the same color as hovered buttons - and that consistently.
Keywords: polish
(In reply to comment #7)
> Are we still seeing this?
Yes.

> Can we please make our theme consistent here?
Consistent with what? (Gnome splitters have no hover colour at all now.)

(In reply to comment #9)
> IMHO it should be the same color as hovered buttons - and that consistently.
That's native-theme dependent, so even less likely to happen.
Sounds like you're effectively saying "WONTFIX" to this. In that case, I'll strike it from the list I'm really paying attention to. I thought that the highlight color would basically be the native background color for hovered buttons but looks like I'm wrong.
(and GNOME splitters are a bad example as they don't have grippies, but I won't argue over this any more)
Gnomestripe splitters have native appearance and in my FC7 VM this draws something resembling a grippy whether or not the <grippy> element exists in the XUL (in this case the grippy can only by detected by the cursor change).
Oh, you mean *gnomestripe* splitters, yes, they have a grippy. GNOME itself doesn't have grippies on splitters, that's why I was thinking of.
Still, I'll leave this to others to care about, I have larger fish to fry.
It's not drawn by gnomestripe, it's a GTK paned widget, whatever that is.
Not sure if this does the right thing for Mac OS
Assignee: nobody → iann_bugzilla
Status: NEW → ASSIGNED
Attachment #397464 - Flags: ui-review?(stefanh)
Comment on attachment 397464 [details] [diff] [review]
Change win/pinstripe to ThreeDHighlight patch v0.1 [Checkin: Comments 17 & 20]

threedhighlight returns white on mac, not sure if that's what you want. In any case, we don't use grippies in the default mac theme, so I'm not sure if you should care about pinstripe.
Attachment #397464 - Flags: review?(neil)
Attachment #397464 - Flags: review?(neil)
Attachment #397464 - Flags: review?(dao)
Attachment #397464 - Flags: review+
Attachment #397464 - Flags: review?(dao) → review+
Component: UI Design → Themes
Product: SeaMonkey → Toolkit
QA Contact: ui-design → themes
Blocks: 277717
Comment on attachment 397464 [details] [diff] [review]
Change win/pinstripe to ThreeDHighlight patch v0.1 [Checkin: Comments 17 & 20]

http://hg.mozilla.org/mozilla-central/rev/3782d23f33e6
Attachment #397464 - Attachment description: Change win/pinstripe to ThreeDHighlight patch v0.1 → Change win/pinstripe to ThreeDHighlight patch v0.1 [Checkin: Comment 17]
Attachment #397464 - Flags: ui-review?(stefanh)
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Comment on attachment 397464 [details] [diff] [review]
Change win/pinstripe to ThreeDHighlight patch v0.1 [Checkin: Comments 17 & 20]

Requesting approval for 1.9.1.x and 1.9.2.x branches. Very simple low risk patch to fix an issue in SeaMonkey. As far as I can see only SM makes use of grippy.
Attachment #397464 - Flags: approval1.9.2?
Attachment #397464 - Flags: approval1.9.1.4?
Attachment #397464 - Flags: approval1.9.1.4? → approval1.9.1.4+
Comment on attachment 397464 [details] [diff] [review]
Change win/pinstripe to ThreeDHighlight patch v0.1 [Checkin: Comments 17 & 20]

Approved for 1.9.1.4, a=dveditz for release-drivers
Comment on attachment 397464 [details] [diff] [review]
Change win/pinstripe to ThreeDHighlight patch v0.1 [Checkin: Comments 17 & 20]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/162d90758cfa
Attachment #397464 - Attachment description: Change win/pinstripe to ThreeDHighlight patch v0.1 [Checkin: Comment 17] → Change win/pinstripe to ThreeDHighlight patch v0.1 [Checkin: Comments 17 & 20]
Which OS is this now fixed on? I see several different descriptions of behaviors above. Which of these is now fixed?
(In reply to comment #21)
> Which OS is this now fixed on? I see several different descriptions of
> behaviors above. Which of these is now fixed?
It's now fixed in Windows and all the grippies turn white instead of purple when you hover over them.
Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090915 SeaMonkey/2.0pre for 1.9.1.4.
Keywords: verified1.9.1
Comment on attachment 397464 [details] [diff] [review]
Change win/pinstripe to ThreeDHighlight patch v0.1 [Checkin: Comments 17 & 20]

approval1.9.2 requests aren't currently being monitored, since we're nearing RC freeze and there are too many outstanding requests, so I'm clearing this request. Feel free to re-request approval if you are confident that it's worth drivers' time to consider whether this non-blocker needs to land for 1.9.2 at this stage.
Attachment #397464 - Flags: approval1.9.2?
You need to log in before you can comment on or make changes to this bug.