-moz-mac-menuselect returns wrong color

RESOLVED FIXED

Status

Core Graveyard
GFX: Mac
--
minor
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: stefanh, Assigned: Josh Aas)

Tracking

Trunk
PowerPC
Mac OS X

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

1.62 KB, patch
Mike Pinkerton (not reading bugmail)
: review+
Simon Fraser
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

12 years ago
On mac OS X, selecting a menuitem will make the background-color turn blueish,
but -moz-mac-menuselect seems to return a hard-coded(?) purple color that was
used in mac OS 9.

fyi, -moz-mac-menuselect is currently used in the mac classic skin, but  will be
removed when the theme make use of the new NS_THEME implementations (menuitem,
menupopup).
Assignee: dbaron → joshmoz
Component: Style System (CSS) → GFX: Mac
QA Contact: ian → mac
(Assignee)

Comment 1

12 years ago
Created attachment 195311 [details] [diff] [review]
fix v1.0

::GetThemeAccentColors(), which we're using to obtain all of these colors, has
no useful values in Aqua. From the header: "GetThemeAccentColors will only work
in the platinum theme. Any other theme will most likely return an error". So
we're always falling back to the default for values like -moz-mac-menuselect.
Most of the defaults suck.

This patch fixes a couple of them, including the one this bug is filed on. This
is not going to do much for us, but we can close this bug out. We don't use
this system any more AFAIK.
Attachment #195311 - Flags: superreview?(pinkerton)
(Reporter)

Comment 2

12 years ago
"GetMacBrushColor(kThemeBrushMenuBackgroundSelected..." doesn't seem to work
either. 
(Assignee)

Comment 3

12 years ago
yeah, there is lots of broken stuff. fixing it all now would be silly. lets just
either 1) land my patch and close this bug and don't file more or 2) dupe this
bug against a bug for cleaning up the whole system.
(Reporter)

Comment 4

12 years ago
(In reply to comment #3)
> yeah, there is lots of broken stuff. fixing it all now would be silly. lets just
> either 1) land my patch and close this bug and don't file more or 2) dupe this
> bug against a bug for cleaning up the whole system.

I first thought that this could be resolved by using a brush color. But I never
got it to work. That's what I ment in comment #2.

Until someone wants to fix the whole system, I suppose a hard-coded color that
is correct is better than a hard-coded one that isn't :)

I'm fine with either 1) or 2), though.




Comment on attachment 195311 [details] [diff] [review]
fix v1.0

r=pink
Attachment #195311 - Flags: superreview?(sfraser_bugs)
Attachment #195311 - Flags: superreview?(pinkerton)
Attachment #195311 - Flags: review+

Updated

12 years ago
Attachment #195311 - Flags: superreview?(sfraser_bugs) → superreview+
(Assignee)

Comment 6

12 years ago
landed on trunk

please no more bugs on this stuff unless we actually use it
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 7

12 years ago
(In reply to comment #6)
>please no more bugs on this stuff unless we actually use it
What about W3C CSS colours, such as Highlight, which I understand currently returns an incorrect colour?
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.