This removes some unnecessary CSS and fixes XUL button height and width.

I'm not 100% sure about the change to button.plain in the theme, I just removed that because I don't know why we'd need it.

This Mac OS X native button should be 66 pixels wide from the dark border line on the left to the dark border line on the right. It should be 21 pixels tall from the dark border line on the top to the dark border line on the bottom. The only thing the toolkit part of this patch does is enforce the correct height and width. Without this patch the width is incorrect in this XUL example. The problem with button heights is really an issue with mozilla/browser pref CSS. This fixes that, but I will be posting another patch to this bug to fix the mozilla/browser CSS in a better way.

This patch does more size enforcement via nsITheme.

Also fixes buttons in Firefox prefs.

Adds some comments, uses constants instead of literals for some things, makes buttons regular size in FF prefs.

Comment on attachment 256124 [details] [diff] [review] fix v2.2 r=mano if you restore the rules for .button-text

Comment on attachment 256124 [details] [diff] [review] fix v2.2 vlad should take a look at this and/or dbaron?

This addresses Mano's comment about .button-text rules, also fixes a problem with add-on enabled button color in selected add-on.

Comment on attachment 256491 [details] [diff] [review] fix v2.3 Obsolete, better fix coming up. I shouldn't have originally removed the color for the "button" selector in buttons.css

Comment on attachment 256519 [details] [diff] [review] fix v2.4 > > /* :::::::::: button :::::::::: */ > > button { > -moz-appearance: button; >+ /* The margin used here come from the Aqua Human Interface Guidelines, >+ there should be 12 pixels between two buttons. */ > margin: 6px; >- min-width: 6.3em; >- -moz-appearance: button; >- padding: 0; >- color: #000000; >+ color: -moz-DialogText; use ButtonText. r=mano otherwise.

this should pass w/ your patch applied. to land in the tree, remove the people.mozilla.com stuff from the test file links, and make them relative to base, e.g. /MochiKit/packed.js.

Comment on attachment 256519 [details] [diff] [review] fix v2.4 sr=me

fix v2.4 landed, unit test landing next

Comment on attachment 256705 [details] [diff] [review] unit test patch v1.0 please add ifdef MOZ_MOCHITEST in the pinstripe Makefile like this one does: http://lxr.mozilla.org/mozilla/source/toolkit/content/tests/Makefile.in (you would do DIRS +=, obviously) r=sayrer with that

test landed

Will this test remain valid if the next OS version slightly changes the look of buttons so they have a different size? (For how many previous versions of Mac OS was it valid?) It seems like we could really use a GetPreferredWidgetSize as well, since you're hard-coding into themes something that nsNativeThemeCocoa could provide, no? (Windows would benefit from such a function as well.)

OK, I see in the patch that you're actually not getting this from the OS, so never mind, I suppose.

(In reply to comment #23) > Will this test remain valid if the next OS version slightly changes the look of > buttons so they have a different size? (For how many previous versions of Mac > OS was it valid?) It may not remain valid. We want to know about that, though. This is the best way to find out. If test maintenance turns out to be a large burden as we gather more of tests, we can revisit test guidelines at that time. > > It seems like we could really use a GetPreferredWidgetSize as well, This might be true, even though it may not apply to this test. Should we file that bug?