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.

Need fix for 1004 (Support CSS2 system colours)

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.

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: Scrollbar 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) Slider (exactly as for scrollbar) Progress Bar (regular) -- you need to look at a screen capture - this is simplified 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 MacAccentRegularShadow MacAccentLightShadow MacAccentFace MacAccentRegularHighlight MacAccentFace MacAccentLightShadow MacAccentRegularShadow MacAccentDarkShadow (only use of this colour) MacAccentDarkestShadow 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?

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 palette.

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)

reassigning to 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: /widget/public/nsILookAndFeel.h /widget/src/xpwidgets/nsXPLookAndFeel.cpp /layout/html/style/src/nsCSSProps.cpp 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 cache. 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 err = NS_ERROR_FAILURE; } } ^^^ missing in attachment

sending out for help, if you cannot help or know of better owner please return

Updating QA Contact to pmac@netscape.com

why was this assigned to simon?

pierre@netscape.com, this is closely related to bug 1004

Marking future and helpwanted. I would love to see this done correctly but cannot find any volunteers.

Not for rtm, marking -

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: -moz-mac-<colourname> 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

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

According to my friends the proper way to render disabled items in macos context menus is display:none.... It would help if a developer.apple.com 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 <http://developer.apple.com/techpubs/mac/HIGOS8Guide/thig-56.html>: `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 altogether. This issue really needs its own bug.

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.

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.

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 4.x?

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.