J Luh Reporter
	Description • 22 years ago

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

	John Keiser (jkeiser)
	Comment 1 • 22 years ago

CC'ing theme dudes

	John Keiser (jkeiser)
	Comment 2 • 22 years ago

->

	Boris Zbarsky [:bzbarsky]
	Comment 3 • 21 years ago

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

	Greg K.
	Comment 4 • 20 years ago

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

	Mike Connor [:mconnor]
	Comment 5 • 20 years ago

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.

	Matt
	Comment 6 • 20 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.

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

	Michael
	Comment 8 • 20 years ago

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?  

	Hiro
	Comment 9 • 20 years ago

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

	Asaf Romano (gone)
	Comment 10 • 20 years ago

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? 

	Boris Zbarsky [:bzbarsky]
	Comment 11 • 20 years ago

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

	TGOS
	Comment 12 • 20 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
}

	Mike Pinkerton (not reading bugmail)
	Comment 13 • 20 years ago

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.

	Asaf Romano (gone)
	Comment 14 • 20 years ago

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

	Asaf Romano (gone)
	Comment 15 • 20 years ago

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.

	jhp (no longer active)
	Comment 16 • 20 years ago

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.

	Asaf Romano (gone)
	Comment 17 • 20 years ago

still, way hacky than it should.

	jhp (no longer active)
	Comment 18 • 20 years ago

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.

	Asaf Romano (gone)
	Comment 19 • 20 years ago

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.

	Kevin Gerich
	Comment 20 • 20 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.

	Ryan Mitchell
	Comment 21 • 20 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... 

	Ben Goodger (use ben at mozilla dot org for email)
	Comment 22 • 20 years ago

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. 

	lists
	Comment 23 • 19 years ago

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

	Simon Fraser [no longer active]
	Comment 24 • 19 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.

	Kevin Gerich
	Comment 25 • 19 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

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

	TGOS
	Comment 26 • 19 years ago

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

	philippe (part-time)
	Comment 27 • 19 years ago

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

	Jo Hermans
	Comment 28 • 19 years ago

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

	Uri Bernstein (Google)
	Comment 29 • 19 years ago

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

	Josh Aas Assignee
	Comment 30 • 17 years ago

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.

	Josh Aas Assignee
	Comment 31 • 17 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.

	Josh Aas Assignee
	Comment 32 • 17 years ago

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

	Josh Aas Assignee
	Comment 34 • 17 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.

	Josh Aas Assignee
	Comment 35 • 17 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.

	Josh Aas Assignee
	Comment 36 • 17 years ago

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

	jag (Peter Annema)
	Comment 37 • 17 years ago

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.

	Josh Aas Assignee
	Comment 38 • 17 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.

	jag (Peter Annema)
	Comment 39 • 17 years ago

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.

	jag (Peter Annema)
	Comment 40 • 17 years ago

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

	Marcus Münch
	Comment 41 • 17 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: 
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.