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

RESOLVED FIXED in mozilla1.9alpha8

Status

()

Core
Widget: Cocoa
P3
enhancement
RESOLVED FIXED
15 years ago
8 years ago

People

(Reporter: J Luh, Assigned: Josh Aas)

Tracking

(Depends on: 3 bugs, {pp})

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

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

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

Updated

15 years ago
Keywords: pp

Comment 1

15 years ago
CC'ing theme dudes

Comment 2

15 years ago
->
Assignee: jkeiser → form
Priority: -- → P3
Target Milestone: --- → Future
*** Bug 223845 has been marked as a duplicate of this bug. ***

Comment 4

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

Updated

13 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

13 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

13 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

Comment 8

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

Updated

13 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)

Updated

13 years ago
Blocks: 237584

Comment 9

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

Updated

13 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

13 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;
 }
 
 
 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.
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.
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

13 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.
Depends on: 275808

Comment 21

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

Updated

12 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

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

Comment 24

12 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

12 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

Comment 26

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

Comment 27

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

Comment 28

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

Updated

11 years ago
Blocks: 301471
(Assignee)

Updated

10 years ago
Assignee: bugs → joshmoz
Component: Layout: Form Controls → Widget: Cocoa
(Assignee)

Updated

10 years ago
Depends on: 369584

Updated

10 years ago
Flags: blocking1.9?

Updated

10 years ago
Flags: blocking1.9? → blocking1.9+
(Assignee)

Updated

10 years ago
Target Milestone: Future → mozilla1.9beta1
(Assignee)

Comment 30

10 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+
(Assignee)

Comment 31

10 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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Comment 32

10 years ago
Reftests fail, turned native form controls off again until we resolve that.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 33

10 years ago
Created attachment 265709 [details]
failed reftests

Updated

10 years ago
Depends on: 381638

Updated

10 years ago
Depends on: 381639

Updated

10 years ago
Depends on: 381644
(Assignee)

Comment 34

10 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.
(Assignee)

Comment 35

10 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.
(Assignee)

Updated

10 years ago
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED

Updated

10 years ago
Depends on: 381775
(Assignee)

Comment 36

10 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

Comment 37

10 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.
(Assignee)

Comment 38

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

Updated

10 years ago
Depends on: 381970

Comment 39

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

Comment 40

10 years ago
For clarity: s/don't want this/don't want the new look/
Depends on: 382048
Depends on: 382049
Depends on: 382050

Updated

10 years ago
Depends on: 154632
Depends on: 382142
Depends on: 382143
Depends on: 382144

Updated

10 years ago
Depends on: 382145

Updated

10 years ago
Depends on: 382147

Updated

10 years ago
Depends on: 382205
Depends on: 383257

Comment 41

10 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.
Depends on: 316317

Updated

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