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

RESOLVED FIXED in mozilla1.9alpha8



17 years ago
10 years ago


(Reporter:, Assigned: jaas)


(Depends on: 3 bugs, {platform-parity})

Mac OS X
Dependency tree / graph
Bug Flags:
blocking-aviary1.0mac -
blocking-aviary1.5 -
blocking1.9 +

Firefox Tracking Flags

(Not tracked)



(2 attachments, 2 obsolete attachments)



17 years ago
Bug 169373 added nsITheme HTML form controls on Windows. The same would be nice
to have on Mac.


17 years ago
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. ***

Comment 4

15 years ago
*** Bug 242164 has been marked as a duplicate of this bug. ***
Assignee: core.layout.form-controls → bugs
Flags: blocking-aviary1.0mac?


15 years ago
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-

Comment 6

15 years ago
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.

Comment 7

15 years ago
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.


14 years ago
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)


14 years ago
Blocks: 237584

Comment 9

14 years ago
*** Bug 224987 has been marked as a duplicate of this bug. ***


14 years ago
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?

Comment 12

14 years ago
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...
Created attachment 172981 [details] [diff] [review]
patch for discussion

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.
Created attachment 173350 [details] [diff] [review]
somewhat better

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.

Comment 20

14 years ago
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.

Comment 21

14 years ago
> 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... 


14 years ago
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-

Comment 23

13 years ago
Any more activity on this?  This is surely a needed feature.

Comment 24

13 years ago
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.

Comment 25

13 years ago
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

Comment 26

13 years ago

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.

Comment 28

13 years ago
*** Bug 318113 has been marked as a duplicate of this bug. ***
*** Bug 326753 has been marked as a duplicate of this bug. ***


12 years ago
Blocks: 301471


12 years ago
Assignee: bugs → joshmoz
Component: Layout: Form Controls → Widget: Cocoa


12 years ago
Depends on: 369584


12 years ago
Flags: blocking1.9?


12 years ago
Flags: blocking1.9? → blocking1.9+


12 years ago
Target Milestone: Future → mozilla1.9beta1

Comment 30

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

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+

Comment 31

12 years ago
This has been turned on for Gecko 1.9a5. If it doesn't work out we'll flip it off until Gecko 1.9a6.
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 32

12 years ago
Reftests fail, turned native form controls off again until we resolve that.
Resolution: FIXED → ---

Comment 33

12 years ago
Created attachment 265709 [details]
failed reftests


12 years ago
Depends on: 381638


12 years ago
Depends on: 381639


12 years ago
Depends on: 381644

Comment 34

12 years ago
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.

Comment 35

12 years ago
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.


12 years ago
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED


12 years ago
Depends on: 381775

Comment 36

12 years ago
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.

Comment 38

12 years ago
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.


12 years ago
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


12 years ago
Depends on: 382145


12 years ago
Depends on: 382147


12 years ago
Depends on: 382205

Comment 41

12 years ago
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.


12 years ago
Depends on: 394127
You need to log in before you can comment on or make changes to this bug.