Closed Bug 175279 Opened 22 years ago Closed 17 years ago

Use nsITheme with HTML form controls on Mac OS X (native-style form controls)


(Core :: Widget: Cocoa, enhancement, P3)






(Reporter:, Assigned: jaas)


(Depends on 3 open bugs)


(Keywords: platform-parity)


(2 files, 2 obsolete files)

Bug 169373 added nsITheme HTML form controls on Windows. The same would be nice
to have on Mac.
Keywords: pp
CC'ing theme dudes
Assignee: jkeiser → form
Priority: -- → P3
Target Milestone: --- → Future
*** Bug 223845 has been marked as a duplicate of this bug. ***
*** Bug 242164 has been marked as a duplicate of this bug. ***
Assignee: core.layout.form-controls → bugs
Flags: blocking-aviary1.0mac?
Flags: blocking-aviary1.0mac? → blocking-aviary1.0mac+
I don't think this is something we're going to do for 1.0.  If a patch comes
around that's safe, great, but I don't forsee this happening.

Please don't set blocker flags if you're not the appropriate person to do so.
Flags: blocking-aviary1.0mac+ → blocking-aviary1.0mac-
I would say it should be a high priority, if MacOS X platform is going to be
targeted, the browser itself should be fitting into the operating system nicely,
just as the Windows version and GTK2 versions do.

Now, sure, I *could* use Camino, but it leaks memory like a sivve, and as for
Opera, well, having run it before, its a real shocker on a slow CPU (such as
this iBook), so the only browser left (apart from Safari) is Firefox.
In the road map of Firefox, it is written clearly as follows.

  Aquafication release. Focus on outstanding UI issues particular to MacOS X,
  redevelop UI to support cross platform nature, etc.

Like the following screen shots, since it is halfway set to Aqua, it is bad also
after user experience.
Summary: Use nsITheme with HTML form controls on Mac OS X → Use nsITheme with HTML form controls on Mac OS X (native-style form controls)
Blocks: macmeta
*** Bug 224987 has been marked as a duplicate of this bug. ***
Depends on: 74058
Well, it isn't really a coding issue.

In order to implement this, we need to 1) Remove the html-content check in
ThemeSupportsWidget (it's #ifndef cocoa) 2) generate style rules for forms.css.

The problems start at (2) - In order to get acceptiable widgets, we need to
avoid some form style rules from website authors (as they don't fit with aqua
widgets), i.e. use !important for some rules in forms.css.

How far we can go here? 
> we need to avoid some form style rules from website authors (as they don't fit
> with aqua widgets)

Er.. shouldn't you just drop native styling if such rules are used?  That's what
the Windows implementation of this does, no?
Yes, we should handle it like Windows. Using Firefox under XP it draws perfeclty
skinned/themed buttons, at least on my computer they look like all the other
Luna buttons do (unless I disable Luna theme, then they look like all the other
plain Windows buttons, so they *do* react to themes). The second I enter a page
were the button is customized with CSS, they are also customized, but not
customized Luna, but customized standard buttons. To pseudo-code it:

if (isCssIsAppliedToButton()) {
    // Draw standard button
    // Apply CSS rules to it
} else {
    // Draw native button
my understanding from when bryner looked at it was that we could do everything
in carbon widget except for the <select> popup becuse of some odd limitation in
carbon. cocoa widget doesn't have this problem.

perhaps bryner could correct my aging memory.
exactly; note we can now use nsitheme menupopup/menuitem which is half-native...
Attached patch patch for discussion (obsolete) — Splinter Review
Well, please ignore the changes in nsNativeThemeMac other than this one:
@@ -739,31 +773,26 @@ nsNativeThemeMac::ThemeChanged()
   return NS_OK;
 nsNativeThemeMac::ThemeSupportsWidget(nsPresContext* aPresContext, nsIFrame*
				       PRUint8 aWidgetType)
-  // Only support HTML widgets for Cocoa
-  if (aFrame && aFrame->GetContent()->IsContentOfType(nsIContent::eHTML))
-    return PR_FALSE;

...the menupopup/menuitem support is needed for this bug, but it is already a
patch the relevant bug.
Interesting start. The scrollbars seem 'detached' in select elements.  Dropdowns
seem to be a little large (see "Email and Numbering"
section).  Checkboxes are squashed horizontally, for some reason.  And smooth
scrolling performance seems to be affected.
Attached patch somewhat better (obsolete) — Splinter Review
still, way hacky than it should.
Attachment #172981 - Attachment is obsolete: true
Latest patch is looking much better.  Dropdown menus still draw a black
background in the menu if I'm using a system theme, but selects look very good,
now.  The text in dropdowns still looks very fuzzy.  Focusing a dropdown shows
both a focus ring around the whole widget, as well as a black rectangular
outline around the text;  should get rid of the rectangle.  There is no similar
focus ring around buttons; in fact, there is no focus indication on buttons. 
Also around text fields.
The textfield focus ring issue can be resolved by some style rules, the button
one isn't (we need to fix nsitheme:mac instead).

I'm not sure what style-rule draws the internal menulist focus rect.
try this for the select (from Camino's forms.css)

select {
  -moz-appearance: menulist;
  margin: 1px 1px 1px 1px;
  background-color: transparent !important;
  color: -moz-FieldText !important;
  font-size: 11px;
  direction: ltr;

This still leaves the black interior border on the select. I can't find the css
rule either. Re the detached scrollbars, Camino has that appearance as well.
Should we adopt Camino's forms.css wholesale? Smooth scrolling isn't affected
AFAIK, though smooth scrolling has always been jerky on my 1Ghz G4 Powerbook.
Depends on: 275808
> Should we adopt Camino's forms.css wholesale? Smooth scrolling isn't affected
> AFAIK, though smooth scrolling has always been jerky on my 1Ghz G4 Powerbook.

If you do this it will need some tweaking, the select elements font size is
horribly wrong (i'm using the latest nightly of Camino), and buttons just never
seem to be the right size, and the vertical font alignment within them isnt
right either... 
Flags: blocking-aviary1.1?
This has potential to cause a lot of problems... unless someone is willing to
drive this effectively and deal with all the issues this has to be - for now. 
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Any more activity on this?  This is surely a needed feature.
I think we just need a much better looking theme for the non-native form controls. Extensions exist which vastly improve them; I don't know why we don't just take their style rules.
I've been messing with my own build with native-looking widgets, hacking forms.css to make the controls look reasonable. You can give it a spin here

I'm sorry, but this theme does not convince me. The drop down boxes on this page look rather ugly and not native. There is a white line before the text, the background color of the opened list does not look native on my Tiger system. So this is already the first issue. The design of the native elements has changed three times from 10.2 to 10.4, always very slightly, but it has changed (as the striped background has).

And your theme does not scale very well if authors try to customize the elemets:

See what I mean? Other widget extensions are better. There is this for example:

I like it, actually I'm using exactly that. The only issue with that hack is that it simply ignores customization of the web page author. Here we need the Windows behavior: If the author styles the controls, make the items plain and apply style instead of using styled controls.

The problem with all these hacks: If Apple changes the look dramatically tomorrow, they all break. Native controls never break and always look right. Camino uses them, so it can't be that hard.
(In reply to comment #25)
Nice, real agua buttons. There are a few problems though, especially with the <select> object. The border surrounding it is quite uneven, there is a kind of white border inside that overlaps the down-arrow. The select[multiple] or select[size] appear to have a transparent background according to your forms.css. This gives strange results when the page has a dark background. Try your build on this test form: <>.
I haven't tried to fix those problems yet; besides, part of it is probably out of my reach.

(In reply to comment #26)

I'm the author of the styling of form widgets in those community builds. That styling is also included in, which is quite popular.
(see my notes: <>, including download links).

I know it is not perfect, but it is the best I could do by only hacking the forms.css. Note that the latest version allow some more page-author customisation. And it was always intended as a stop gap measure while waiting for real native widgets. Josh Aas has started working on real cocoa widgets, afaik.

While we are on the subject, it might be a nice idea to include a preference option: allow page authors to style form widgets: yes/no.
Opera has this option, and I find it very nice.

*** Bug 318113 has been marked as a duplicate of this bug. ***
*** Bug 326753 has been marked as a duplicate of this bug. ***
Blocks: 301471
Assignee: bugs → joshmoz
Component: Layout: Form Controls → Widget: Cocoa
Depends on: 369584
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Target Milestone: Future → mozilla1.9beta1
Attached patch fix v1.0Splinter Review
When we have approval for Mac OS X native form controls in Gecko 1.9 (a5 major changes window is over), this will enable them.
Attachment #173350 - Attachment is obsolete: true
Attachment #265638 - Flags: superreview?(roc)
Attachment #265638 - Flags: superreview?(roc) → superreview+
This has been turned on for Gecko 1.9a5. If it doesn't work out we'll flip it off until Gecko 1.9a6.
Closed: 17 years ago
Resolution: --- → FIXED
Reftests fail, turned native form controls off again until we resolve that.
Resolution: FIXED → ---
Attached file failed reftests
Depends on: 381638
Depends on: 381639
Depends on: 381644
I have done a pretty extensive comparison of the rendering for 84400-1.html and 273681-1.html and I don't see any different at all. I've even compared color values for almost every pixel.

I do see differences in 28811-2a.html and 28811-1a.html vs. their references. The difference in both is that one has a scrollbar at the bottom of the containing box and the reference doesn't.
I checked this in again, marking 2 of the reftests as fail with a bug #, 2 of them as random with no bug #. I don't know what is wrong with the latter two, they look exactly the same to me.
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Depends on: 381775
This was backed out again, and now I've checked it in again, with more reftest failures filed and marked.
QA Contact: tpreston → cocoa
Is there a way to turn this off? I'm using the modern Theme with SeaMonkey and I prefer the way the controls looked before this change.
You can back out the patch on this bug to turn them off. Or you can set "-moz-appearance: none;" on the controls in content.
Depends on: 381970
Since I build my own I guess I can do that locally. I could also put it under a (hidden?) pref, though if others don't want this perhaps we should key this behaviour off either a visible pref or the theme or something.

Let me think about this for a bit, poll people, and I'll open a new bug if needed for further discussion.
For clarity: s/don't want this/don't want the new look/
Depends on: 154632
Depends on: 382145
Depends on: 382147
Depends on: 382205
Depends on: 383257
Well, the last alpha releases have this nice native form controls, but: while typing this I use the brandnew Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a6) Gecko/20070629 GranParadiso/3.0a6, and I must say that the rendering of webpages is significantly slower than in Firefox 2.0 on Mac. I checked all bugs this bug depends on, and also searched Bugzulla, but did not see any bugreport about this issue, although it is mentioned here i think:
To reproduce this, open in Firefox 2.0 (the page is shown nearly instantly on my Mac) and Firefox 3.0 Alpha 6 (takes about ten seconds until the progress indicator stops), to see the difference. I am not shure, if I should open a new bug on this topic, or if I'm just to blind to find an already reported bug.
Depends on: 394127
Depends on: 482761
You need to log in before you can comment on or make changes to this bug.