Closed Bug 46174 Opened 24 years ago Closed 24 years ago

[Mac Classic] Widgets don't use Appearance Manager variation color


(SeaMonkey :: Themes, defect, P3)



(Not tracked)



(Reporter: lordpixel, Assigned: hangas)



(Keywords: classic, platform-parity)


(10 files)

Moz build 200007213

Mac Classic skin uses default "Lavender" blue for scrollbars, drop down menus
(like the Bookmarks in the personal toolbar) an dropown lists (like the font
choosers) and list boxes in HTML are using a darker blue

It should be picking up the user's Variation colour from Appearence.
I think knowing about the variation color involves making a CSS value for it 
which hasn't been done yet ... But menus should still be identical to how they 
normally look with the Mac OS default, which is Lavender.
A Couple Things: First, there is currently no underlying code in Netscape 6 to be 
able to grab the Mac system colors from the Appearance control panel.  I 
completely agree that it should grab whatever the user's system preferences are, 
but currently this is a very low priority.  The reason this feature doesn't 
already exist in the first place is due to Mozilla's goal to being truly cross-
platform, relying on as little info from any particular OS as possible.  I hope 
to get this fixed on the Mac soon though.

Second, the appearance of HTML widgets (like list boxes) are a different matter 
entirely.  In order to make it easier for web designers, we have designed a 
standard widget set that has a standard size and appearance no matter what the 
user's skin is.  The idea is that the skin only affects the mozilla app, and not 
any independant data that is being viewed through the browser, even though it 
detracts from the overall appearance.  The standard widget set is also a good for 
making Mozilla easily embeddable.
Ever confirmed: true
Need fix for 1004 (Support CSS2 system colours)
Depends on: 1004
Blocks bug 39375 (platform-consistent look and feel for widgets). Also applies to 
focus rings, to progress meters, and (even though Apple doesn't do it) to 
disclosure triangles.

Doesn't really depend on bug 1004: as discussed in that bug, a Moz-specific CSS 
value needs to be added to cater for the Mac's variation color. That needs a 
separate bug.

Scrollbars and progress meters depend on bug 31726 (tinting of graphics), since 
they use various tints of the variation color.

Nikhil, if you know exactly who it was who came up with that utterly fallacious 
idea that having a cross-platform HTML widget set would `make it easier for web 
designers', please let me know and I'll have a quiet word with them. (Apparently 
they think Mozilla is the only graphical Web browser in existence ...)

This bug will probably be split up into half a dozen other bugs when I get the 
time to do it.
Blocks: 39375
Depends on: 31726
Summary: [SKINS] Mac Clasic Skin: Scrollbars, drop down lists and menus use the wrong highlight colour → [Mac Classic] Widgets don't use Appearance Manager variation color
Matthew - The idea behind having a standard size widget set has little or nothing 
to do with a belief that Mozilla is the only graphical browser on the market.  
The idea, which I agree with, has to do with a basic separation of content and 
view/presentation/UI that is good programming style.  I agree that the current 
embedded widget set is pretty damn ugly, but that doesn't mean that the idea to 
have a standardized widget set is not a good one.  And once the resources are 
available, the ability to skin the embedded widget set will come about...And this 
entire discusssion will be irrelevant.
> The idea behind having a standard size widget set ... has to do with a basic
> separation of content and view/presentation/UI that is good programming style.

And having a standard size widget set would *discourage* that separation of 
content and view, and *discourage* good programming style, because it would 
encourage authors to assume that the same size widgets were being used 
everywhere -- when this would simply not be the case. (Much the same way as 
authors used to assume that text would be in Times New Roman unless they took 
drastic steps to prevent it.)
There is nothing wrong with moving toward a cross-platform standardization of 
widgets.  There is an ideal that suggests that everything (including style, hence 
we have CSS as a standard) in a web page's content should be under the content 
provider's control, and that the browser is simply an outer frame on this 
content.  Short of being able to control what the widgets actually look like and 
how they behave, the content provider can at least be sure that their web page 
looks good across ALL platforms by testing it with the standard widget set.  
There is nothing wrong with this ideal.  

Ultimately, though, the content will be under 
the user's control, just as you can have preferences for fonts and other settings 
that you can set to override the content provider's choice.  In this way we will 
eventually (hopefully) have a user preference to determine which widget set the 
user would like to use: the standard, the current skin-specific, or one that is 
even part of a separate skin that is not the currently active one.

I dislike the current look of the embedded widgets as much as anyone else.  
They're really ugly, esp. on a Mac.  That doesn't mean that the idea to have 
standard widgets is a bad one though.
Been having my usual weekend dig around.

To get the Accent/Variation colours for the current theme on calls 
GetThemeAccentColors			(CTabHandle *			outColors)	

which essentially returns a Quickdraw ColorTable containing 7 colours that make 
up the variation color. (Gold, Lavendar, Sunny or whatever).

This is a Platinum concept - other themes generally don't have Variation colours, 
so one must check for errors after calling this. (Lord knows what Aqua will do - 
I'll try to find out)

So to fix this bug, I think we need to add some constants to mozilla/source/
widget/public/nsILookAndFeel.h to capture the concept of scrollbar colours, then 
make alterations to mozilla/source/widget/src/mac/nsLookAndFeel.cpp to actually 
use GetThemeAccentColors to get the user's current colors. (Defaulting to 
Lavendar if the routine fails I guess).

Naturally, if one is adding these kinds of colour constants, one needs to make 
sure they return something sane on Linux and Windows, or add them in a place 
that's definately Mac specific.
The return value of GetThemeAccentColours isn't documented, so I went and worked 
it out. All the actual colour values below are examples - they're what you get if 
you use the Gold Accent/Variation colour scheme. The important thing to note here 
is the indexes 0..6 and which colour they correspond to. I made the names up, but 
I think they're suitably descriptive.

	0 	MacAccentLigtestHighlight		#ffff99	
    1	MacAccentRegularHighlight		#ffff00	
    2	MacAccentFace			 		#cccc00	
    3	MacAccentLightShadow		 	#999900	
    4	MacAccentRegularShadow		 	#666600	
    5	MacAccentDarkShadow 			#333300	
    6	MacAccentDarkestShadow 			#111111	
Controls use the colours as follows:


Top left corner			MacAccentLightestHighlight
Top and left sides 		MacAccentRegularHighlight
Face 					MacAccentFace
Bottom and left sides	MacAccentLightShadow
Grippy shadow			MacAccentRegularShadow
Grippy highlight		MacAccentRegularHighlight
Grippy "gleam"			MacAccentLightestHighlight (single pixel at the end of 
each ridge on the grippy)


(exactly as for scrollbar)

Progress Bar (regular)  -- you need to look at a screen capture - this is 

Central highlight				MacAccentLightestHighlight
First ring out from centre		MacAccentRegularHighlight
2nd ring 						MacAccentFace
3rd ring						MacAccentLightShadow
4th ring						MacAccentRegularShadow
botttom and right of shadow		MacAccentDarkestShadow

Progress bar, barber poll (denotes indeterminate progress)

Coloured part consists 10 stripes, as follows: (there is also the Silver part)

MacAccentDarkShadow				(only use of this colour)

Focus Ring

MacAccentLightShadow		(though you should use the GetThemeBrushAsColor call 
to get this)

Drag highlight (indicates a region is a valid drop target)

Use call to GetThemeBrushAsColor
How about using Appearance Manager itself to draw the scrollbar graphics? Couldn't 

Mozilla ask Appearance Manager to draw the relevant scrollbar parts in an off-screen 

GWorld at run-time? Then Mozilla could slice up the resulting bitmaps, cache the slices 

and let the slices be accessed through pseudo URLs.

This way the scrollbars would also be compatible with many/most Kaleidoscope themes.
Please see bug 38275. Something like this is indeed planned for the future.
Bug 38275 doesn't look relevant. Wrong bug number perhaps?
Keywords: classic, pp
oops. bug  39375
What I suggested would count as a stage 2 implementation. I believe using OS-drawn 
cached bitmaps is more efficient than constructing bitmaps using gfx and an OS-supplied 
Henri, if you want that stuff file please a different bug. Thanks. This bug is 
for the CSS colors and such for native coloring of moz widgets.  A minor 
reminder: We're allowing windows native widget support to rot, so don't expect 
anyone to work on mac native widget support [with the exception of menus which 
we do because...].  One of the reasons is that skin functionality demands more 
features than we can easily expose through native calls.
The arguement that the os can draw faster than mozilla is generally silly.  
Unless your OS uses 90% of all cpu cycles and gives 10% to the active app, 
there should be no reason that what one binary (mozilla) does should be any 
faster or slower than what another binary (system/guisubsystem) does.
Adding CCs [not related to my comments, but because of the bug itself]
Nominating for rtm, cause the Mac community will fry us without this! I know 
MacIE5 has a similar problem, but its no where near as annoying.

I hope to get some time to work on this this week, but it will likely be to a 
similar quality standard as my patch attached to bug 1004. i.e. the basics will 
be there but it won't work. I need someone who can build on MacOS to help out!

>The arguement that the OS can draw faster than mozilla is generally silly.  

Really? You believe that Mozilla can blit just as fast, through all its layers 
of CSS, XUL, GFX and Dilbert knows what else, as the Mac Toolbox Quickdraw 
routines that Apple has been tuning since 1984? 

Mozilla is emulating natvie controls through several layers of APIs. With the 
best will in the world this *is* going to be slower. The questions are, is it 
slower enough to be noticable? Is it fast enough to be acceptable?

It seems OK to me, but then I have a G4 not a PowerPC 601 (G1, if you like)
Keywords: rtm
reassigning to hangas
Assignee: nbhatla → hangas
//This rant is directed at everyone, not just timeless.

Timeless: lordpixel is right: Mac OS can probably draw the controls faster than 

Mozilla. And even if Mozilla could draw them faster, I'd still be against having 

Mozilla draw any widgets that the host OS provides.

And he's also right that the Mac community will fry Mozilla for not looking like 

every other Mac application. It doesn't MATTER that it's cross platform, and has 

all the latest features, can wash your dishes, make your toast, and walk your 

dog. If it doesn't look like a Mac app, it isn't a Mac app, and many Mac users 

will shun it for THAT REASON ALONE.

The Host OS, whether it's Mac OS, Mac OS X, Windows, BeOS, or whatever, provides 

a set of native widgets for three basic reasons. First, it's just *easier* to use 

OS widgets than to code your own. Second, it makes all the applications that use 

those widgets look consistent. Thirdly, it allows the OS vendor to add features 

to those widgets and have them take effect on a global basis.

Take the Mac transition from Classic B/W to Classic Color to Platinum to Aqua. An 

application written back in 1984 using native widgets would, with minimal effort, 

incorporate all the new functionality and appearance of widgets introduced in 

successive updates to the Mac OS user interface. A program written before the 

zoom box benefited from its addition with no extra code. Then Apple added color 

tinges to the windows and controls and apps got that for free. Then WindowShade 

was incorporated into the OS and apps got that for free. Then the Appearance 

Manager came along and apps got UI enhancments mostly for free. And again with 

Aqua. Your well-written app has to do nothing to get those throbbing buttons and 

window drop shadows and that gawd-awful genie effect to the dock.

Heck, Mozilla requires 8.5. This means that Appearance 1.1 can be assumed to be 

present, which means there's a TON of native widgets that can be used without the 

need to reimplement them.

There's another few bugs in the system that complain about the number of open 

files, and the fact that the Mac install has over THREE THOUSAND files that get 

installed. Maybe some of these files wouldn't be necessary if Mozilla just used 

native widgets instead of trying to define the looks of widgets in some XML file?

The point of this rant, which should probably be copied to every other user 

interface bug for every OS, is that it's just plain *silly* to duplicate the 

native widgets with less attractive Mozilla widgets that are "cross platform". 

The Appearance Manager is there for a *reason*. Apple added a ton of new controls 

for a reason: too many app developers were using too many different variations of 

controls that should have been system-wide to begin with.

"Relying on as little info from any particular OS as possible" is not being 

crossplatform. Being crossplatform is saying "Give me a scroll bar with these 

dimensions, with a page height of XXXX pixels, YYY of which are visible, and 

we're displaying starting at ZZZ pixels" and letting whatever OS-specific glue 

you need ask the OS to do that. And then you don't care if the user chose 

Lavender or Magenta or Puke Green as their accent color, because the OS drew the 

thing for you. Ask for a scroll bar in your XP front-end, and let your OS-

specific backend library take care of the details.

Part of responsible software development is adhering to the standards of the host 

OS. Part of responsible software development is writing efficient code.

And especially, part of responsibile software development is knowing WHEN to 

reinvent the wheel. Mozilla is reinventing too many wheels just for the sake of 

reinventing them.

//End Rant.

If you care so much, please help us support native widgets by submitting 
patches. The engineers who are already working on Mozilla (including all the
Netscape engineers) are waaay too busy to do this. We have plenty of other,
more important bugs to fix (like crashers).

And FYI: If Mozilla had not gone the XUL/XBL route, then Netscape would not be
working on a browser for the Mac at all.
First, go read my comments on the patch attache to bug 1004.

You need to do this for 2 reasons:

i) this file also contains the bug 1004 work

ii) THIS CODE  is even WORSE than that code!

I'm ashamed to attach something this bad. The only use it has is to act as a 
starting point and a demonstration for someone who really wants to take this on 
of the most basic points needed to begin.

This is a single function whose job is to fetch a Mac accent variation colour 
when passed the appropriate constant, or default to using the Lavendar colours if 
something goes wrong.

Its not wired into the style system. What's needed is:

i) Someone compile debug and fix this function

ii) Someone needs to add some extra proprietary Moz CSS system colour constants 
so the rest of the application can find these mac accent colours

The first question you need to answer is whether the constants that you add can 
remain Mac specific or whether you need to give them dummy/sane colour values on 
all other platforms (Win, Linux, OS2, BeOS).

I worry that its the later because as far as I can tell adding new constants to 
the style system would require updates to at least these files:


So I doubt you can contain it to Mac OS only :-( but I don't know that for sure. 
Also if you call the constants something like eColorMacXXXX you can just maybe 
note they're undefined on other platforms, because they make no sense.

You also need to define constants for the Focus Ring, Menubar selected colour, 
and drag highlight, and wire these up to GetThemeBrushAsColor as suggested above 
and demonstrated (for the official CSS2 system colors) in the part of the patch 
that relates to bug 1004.

A further issue is that of speed. I don't know how often Netscape calls GetColor 
- if its just at startup or occassionally, like during New Window, then we're 
probably OK with this, but I wonder about caching the colours to speed things up 
rather than querying the Appearance Manager every time. Of course. maybe looking 
these up is so fast it doesn't matter...

If we cache the colours then you need to look at the docs linked off bug 1004 and 
evaluate how difficult it will be to get Mozilla to respond to the Apple events 
sent when the systemwide theme changes so it can flush and rebuild the colour 

Actually, we may need to react to these events to be fully Appearance compliant 
in any case.
I don't think I was clear enough on this so:

My C is rusty. I can't build Mozilla so I can't compile this. You need to be 
checking *everything* including going right down to the level of grubbing through 
Quickdraw.h  to make sure I'm dereferencing the data structures correctly.

Read the comment in bug 1004.
Sigh - missed a close brace:

	} else {
		//hmmm, MacOS constant! what should I be using?
		if (colours == NIL || (**colors)->ctSize !=7) {
			//someone changes the struct on us
    ^^^ missing in attachment

Blocks: 49144
sending out for help, if you cannot help or know of better owner please return
Assignee: hangas → sfraser
Updating QA Contact to
QA Contact: paw → pmac
why was this assigned to simon?
Assignee: sfraser → hangas, this is closely related to bug 1004
Marking future and helpwanted.  I would love to see this done correctly but 
cannot find any volunteers.
Keywords: helpwanted
Target Milestone: --- → Future
Not for rtm, marking -
Whiteboard: rtm-
Here is a working C++ patch. Its not a complete fix to this bug but it does make 
4 mac colours available:

1/ The Focus ring colour (primarily for text fields, but listviews and trees 
should use it)
2/ The colour of a selected menu item [*]
3/ The colour of text in a selected menu item
4/ The colour of the drop target focus ring in drag and drop operations.

These patches add extra constants to CSS following the naming convention:


n.b. this patch incorporates the patch I made for bug 1004. There's no avoiding 
it, this builds on that work.

While the constants are visible on all platforms they only have sensible values 
on Mac OS. This is OK because they're only for use inside the Mac classic skin.

The second attachment is a patch to classic/global/mac
menu.css and textfield.css that show off the C++ patch.

The patch to menu.css can be considered complete, in that it implements all of 
the Mac colours that are currently defined. The patch to textfield.css simply 
implements the focus ring, ignoring any other hard coded colours in this file. I 
will open a bug on hardcoded colours in the Mac Classic skin.

[*] currently this is a couple of shades too light. To fix this I need to 
ressurect parts of the older non-working patch (from 08/09/00) on this bug
Keywords: patch, review
OS: All
Whiteboard: rtm- → rtm- [review attachments: 17505 and 17506 please]
Blocks: 57490
Blocks: 39582
Improved patches now query variation colours.
This corrects the menu problem mentioned earlier. 

C++ patch
supports variation colours
support Black & White high contrast platinum theme variation
apologies, patch 17947 has mac line endings.

menu.css patch
Also added support for properly displaying disabled item in Mac popup/contextual 
menus  - this patch is just for demo purposes. Final version will be posted on 
bug 57490
Whiteboard: rtm- [review attachments: 17505 and 17506 please] → rtm- [review attachments: 17947 and 17948 please]
According to my friends the proper way to render disabled items in macos 
context menus is display:none.... It would help if a url or 
equiv was included here showing that disabled context menu items can exist 
before we consider your last changes.
-end of confusion-
Of course mozilla doesn't care about macui standards so coloring it correctly 
is still a step forward and you can ignore this comment if you like.
As always thank you for working on this project
The HIGs say <>: 
`Contextual menus should never supersede menu bar items; there shouldn't be any 
items in a contextual menu which are not also accessible through the menu bar'. 
(We break that rule anyway, see bug 34357.) And later: `You should never place a 
command in a contextual menu which is disabled in or cannot be chosen from 
another menu in the application'.

I am inclined to think that this is poor wording on Apple's part, and that they 
actually meant the following. `You should never place a command in a contextual 
menu which is not available in the menu bar. In addition, you should never enable 
a command in a contextual menu if it is disabled in the main menu bar.'

I see nothing wrong with disabled items in context menus /per se/ -- see my
2000-10-25 comment in bug 16081, for example, where having disabled items in a 
context menu is important to make the position of the other items consistent with 
related context menus. In any case, we have other non-native menus in the UI 
which might have disabled items, and this patch is not specific to context menus.
mpt: No, Apple means what they say: contextual menus should _never_ have
disabled items. If an item is disabled, then it doesn't apply to the context in
which the menu opened. If it doesn't apply to the context, then it shouldn't
show up in a contextual menu.
hrm. Yeah. What I was doing was making the contextual menu items behave visually
like disabled items in the main menus in the menubar. But John and timeless are
right, Apple produced software never has (that I've seen) any disabled items in
a contextual menu, so display: none; is probably the right thing to do.

Of course, this *probably* only makes sense if the items are available (but
disabled) in some other menu in the menubar, otherwise we're hiding the option

This issue really needs its own bug.
Depends on: 57799
Blocks: 53927
Blocks: 59887
Keywords: rtm
Whiteboard: rtm- [review attachments: 17947 and 17948 please] → rtm- [review attachment: 19436 please]
Ok Ben G and Pierre have looked at this and OK'd it (with one minor change Ben
wanted to make the drag highlight colour cross platform).

Simeon (smfr) do you still you look at this? If not I'll go for a= from blizzard
Implementation on Win/Linux uses text highlight colour.

Other platforms (OS2, BeOS etc) will just get their default colour for unknown 
colours, which is seems to be either black or white.
Whiteboard: rtm- [review attachment: 19436 please] → rtm- [review attachment: 20147 please]
OK, now I have sr=blizzard via email.

(hmm, 3 people reviewed this and none of them commented in the actual bug :-) 
good thing you guys know me huh?)
Fix checked in.  Thanks for the patch, lordpixel.
Closed: 24 years ago
Resolution: --- → FIXED
This bug is partially fixed on Mac (2001-01-09-08-Mtrunk). The highlight menu 

items show different color other than Lavender. However, the color that appears 

around the text field when you click on does not take any change. These two 

colors should be identical colors.

To show different color other than Lavender, open the Appearance Control Panel, 

go to Appearance tab, make sure the Appearance is "Apple Platinum" then change 

the Variation color to something other than Lavender.

I checked with the Netscape 4.x, the text field focus ring when you click on 

does not change any color. Does Netscape 6 want to change different than Netscape 


Netscape 4.X has very bad support for modern Mac standards. It just used black 
focus rings. This was what System 7 did but not Mac OS 8. While the classic skin 
is supposed to be like Netscape 4 engineering in its failings is probably taking 
that too far!

Are you saying that focus rings are not changing colours for you? I don't mean 
the border of the field but the ring that appears around it when you click in it 
(e.g. see the Name field on the Personal tab of the Internet control panel).

If these rings are stuck as lavender on your system can you give me/us a specific 
example of one which does not change?

2 which definately work on my system:

1/ The Home Page location text field on the Navigator tab in preferences

2/ The Search field on the Search tab of the sidebar.

Are these really stuck on lavendar on your system? 

If you change the colour in the Appearence control panel you might have to quit 
Mozilla and restart it for the colour to change -> there is a seperate bug on 
that issue. That's bug 57799.

Thanks very much for your explanation, Andy! Yes, the focus ring around
it when you click in does change different color other than lavender.

It works on my system with the following:

1. The Home Page location text field on the Navigator tab in preferences
2. The Search field on the Search tab of the sidebar.

Andy, your explanation is very clear. Thanks again!  I think the scroll 
bar is still blue. Maybe this is a separate bug. Anyway, marking verified 
on Mac; OS: 9.0 (2001-01-12-08-Mtrunk).
Marking verified on Mac; OS: 9.0 (2001-01-12-08-Mtrunk).
Mac Scrollbars are the WRONG COLOUR is Bug 65025.
Keywords: helpwanted, patch, review
Whiteboard: rtm- [review attachment: 20147 please]
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.