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

Status: RESOLVED FIXED

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

Description

[J Luh]

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

Comment 1

[John Keiser (jkeiser)]

CC'ing theme dudes

Comment 2

[John Keiser (jkeiser)]

->

Comment 3

[Boris Zbarsky [:bzbarsky]]

*** Bug 223845 has been marked as a duplicate of this bug. ***

Comment 4

[Greg K.]

*** Bug 242164 has been marked as a duplicate of this bug. ***

Comment 5

[Mike Connor [:mconnor]]

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.

Comment 6

[Matt]

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

[Hiro]

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.
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=1608&action=view

Comment 8

[Michael]

Why not include the improvements from http://kmgerich.com/archive/000072.html or
http://hicksdesign.co.uk/journal/551/native-looking-firefox-os-x-widgets for now?  

Comment 9

[Hiro]

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

Comment 10

[Asaf Romano (gone)]

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? 

Comment 11

[Boris Zbarsky [:bzbarsky]]

> 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

[TGOS]

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
}

Comment 13

[Mike Pinkerton (not reading bugmail)]

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.

Comment 14

[Asaf Romano (gone)]

exactly; note we can now use nsitheme menupopup/menuitem which is half-native...

Comment 15

[Asaf Romano (gone)]

Attachment: patch for discussion

Well, please ignore the changes in nsNativeThemeMac other than this one:
@@ -739,31 +773,26 @@ nsNativeThemeMac::ThemeChanged()
   return NS_OK;
 }
 
 
 PRBool 
 nsNativeThemeMac::ThemeSupportsWidget(nsPresContext* aPresContext, nsIFrame*
aFrame,
				       PRUint8 aWidgetType)
 {
-#ifndef MOZ_WIDGET_COCOA
-  // Only support HTML widgets for Cocoa
-  if (aFrame && aFrame->GetContent()->IsContentOfType(nsIContent::eHTML))
-    return PR_FALSE;
-#endif
-

...the menupopup/menuitem support is needed for this bug, but it is already a
patch the relevant bug.

Comment 16

[jhp (no longer active)]

Interesting start. The scrollbars seem 'detached' in select elements.  Dropdowns
seem to be a little large (see
https://bugzilla.mozilla.org/query.cgi?format=advanced "Email and Numbering"
section).  Checkboxes are squashed horizontally, for some reason.  And smooth
scrolling performance seems to be affected.

Comment 17

[Asaf Romano (gone)]

Attachment: somewhat better

still, way hacky than it should.

Comment 18

[jhp (no longer active)]

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.

Comment 19

[Asaf Romano (gone)]

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

[Kevin Gerich]

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

[Ryan Mitchell]

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

Comment 22

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 23

[lists]

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

Comment 24

[Simon Fraser [no longer active]]

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

[Kevin Gerich]

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

http://kmgerich.com/downloads/deerpark-kmgerich-1.5.en-US.mac.dmg

Comment 26

[TGOS]

@Kevin:

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:

http://game1.andaloria.de/Login.php

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

http://www.furbism.com/firefoxmac/

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.

Comment 27

[philippe (part-time)]

(In reply to comment #25)
 
> http://kmgerich.com/downloads/deerpark-kmgerich-1.5.en-US.mac.dmg
> 
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: <http://dev.l-c-n.com/forms/form1_black.php>.
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 Firefoxy.app, which is quite popular.
(see my notes: <http://emps.l-c-n.com/articles/94/widgets-for-firefox>, 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

[Jo Hermans]

*** Bug 318113 has been marked as a duplicate of this bug. ***

Comment 29

[Uri Bernstein]

*** Bug 326753 has been marked as a duplicate of this bug. ***

Comment 30

[Josh Aas]

Attachment: 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.

Comment 31

[Josh Aas]

This has been turned on for Gecko 1.9a5. If it doesn't work out we'll flip it off until Gecko 1.9a6.

Comment 32

[Josh Aas]

Reftests fail, turned native form controls off again until we resolve that.

Comment 33

[Josh Aas]

Attachment: failed reftests

Comment 34

[Josh Aas]

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

[Josh Aas]

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.

Comment 36

[Josh Aas]

This was backed out again, and now I've checked it in again, with more reftest failures filed and marked.

Comment 37

[jag (Peter Annema)]

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

[Josh Aas]

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.

Comment 39

[jag (Peter Annema)]

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.

Comment 40

[jag (Peter Annema)]

For clarity: s/don't want this/don't want the new look/

Comment 41

[Marcus Münch]

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: 
http://wiki.mozilla.org/Mac:Cocoa_Widgets
To reproduce this, open http://www.spiegel.de 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.