Right now native buttons drawn with HITheme can only draw at height 17, 19, and 22 or higher. So, if we want a size 15, 16, 18, or 20 button for example, we can't draw that. This is an HITheme limitation. To solve this problem, I propose drawing into an offscreen buffer and scaling the images such that we don't distort the endcaps.

This allows us to render any size greater than 20x12, a huge improvement over what was effectively 70x22. If we need to do any offscreen scaling, we first resize to adjust height only and if we need to shrink the width we do that by "cutting out the middle" of the image to preserve the shape of endcaps. This has one major bug remaining, and it could use a couple more comments. The bug is that since we now set min-width and min-height on chrome buttons to conform to Apple HIG, the button/icons in the URL bar got a lot taller and the URL bar is thus too tall. I haven't figured out how to stop that from happening yet. Mano - any ideas?

set min-width/height for these in browser's browser.css; it already has rules for overriding -moz-appearance for these buttons. Another approach would be to keep the current nsNativeTheme sizes in place for the xul namespace and not set min-width/height in button.css at all.

This fixes the URL bar issue with v0.9 and also fixes bug 376695.

Need to make sure to draw into the CGContext we're given in DrawButton instead of the current graphics context. Thanks for pointing that out cbarrett.

Comment on attachment 263326 [details] [diff] [review] fix v1.0.1 Looks good to me. Excited about this!

Does this applies to disabled html buttons as well? On my Camino build with patch v1.0, a disabled input[type="submit"] is 2px taller than the enabled one.

I'd rather you not test this stuff in Camino until Camino stops using its own CSS for things. Because it uses that CSS bug reports from Camino don't really mean much.

Don't remove the margin around .button-text, it will break iconic buttons. Also, s/0px/0/

Comment on attachment 263379 [details] [diff] [review] fix v1.0.2 r=mano on the toolkit & browser bits.

Comment on attachment 263379 [details] [diff] [review] fix v1.0.2 sr=pink

landed on trunk

I backed this out because it broke 3 mochitests and no-one was around to clean up.

The unit test failures let me to finding some other things to fix. First of all, the Apple HIG documentation says that the minimum button size should be 68, but that is a type and it is actually 79. I have filed that doc bug with Apple and fixed that in this patch. Secondly, it turns out HITheme can render buttons at widths as small as 28. That is small enough for us so I made the minimum width 28 and it eliminates the need to ever make a second offscreen buffer for width scaling. Third, I have changed the pinstripe button test itself to reflect the minimum chrome aqua button size, have better descriptions, and I eliminated the button-small test because that doesn't really mean anything any more (it doesn't have a different minimum size than a regular button).

Comment on attachment 263436 [details] [diff] [review] fix v1.1 assuming these huge buttons look OK ;) Please file a bug on cleaning up button-small usage in Pinstripe, I would bet this breaks the appearance of the buttons in the toolbar customization dialog.

landed on trunk again, filing followup per comment #15

+[NSGraphicsContext graphicsContextWithGraphicsPort:flipped:] was introduced in 10.4. When running on 10.3, we get: *** +[NSGraphicsContext graphicsContextWithGraphicsPort:flipped:]: selector not recognized http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/widget/src/cocoa/nsNativeThemeCocoa.mm&rev=1.24&mark=186#184 http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSGraphicsContext_Class/Reference/Reference.html#//apple_ref/occ/clm/NSGraphicsContext/graphicsContextWithGraphicsPort:flipped:

checked in a compile fix that just renders to the current context, filed bug 379640 on rendering to the correct context