User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.9a1) Gecko/20060712 Camino/1.2+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.9a1) Gecko/20060712 Camino/1.2+ The text-label for buttons (input[type="submit"], input[type="button"], etc) is incorrectly aligned with surrounding text, or with other form widgets. the whole button is postioned to high. Caused by the 4px bottom margin in forms.css (line 629 in my copy). Safari (both release builds and recent nightly Webkit builds) align those correctly. At OS level, the label for similar buttons is equally aligned to the surrounding text. Reproducible: Always

Screen shot of the test case, Camino and Safari (WebKit build 15369) side by side.

Bottom of save as dialogue box in Textedit.app

These problems are also mentioned in bug 324501 comment 2, and in bug 298111 comment#c16 and 21

Try this one. Changelog 1/ adjusted the margins on input[type="submit"], input[type="reset"], input[type="button"] to correct the vertical alignment. 2/ keep some margins on top and bottom to keep the buttons separated (vertically) in a tight alignment (small line-height, constrained table based layouts). The value is less than what Safari uses (total distance will be 3px vs 5px in Safari), but Safari uses much smaller buttons. It matches what Opera does. 3/ Add an !important statement to the border rule. Forces the buttons to keep their border and shape. Currently, if the page author specifies some small (0 or 1px border), the Camino buttons lose their shape and overflow their html box (and cause the text-label to be positioned out of alignment), which potentially cause an overlap. See some tests in attachment 138185 [details] (https://bugzilla.mozilla.org/attachment.cgi?id=138185) in bug 228499. 4/ Added height:auto !important. The Gecko buttons have -moz-box-sizing: border-box; set. This means the compute height is equal to the height as stated in a CSS rule (the height includes border + padding box). This rule prevents the label from vanishing if a very small height is specified by the page author. The last two mods may be contentious, as it means the buttons are less 'styleable'. Personally, I don't see this as problematic. Camino's buttons are _basically_ not style-able by page authors, beyond setting font-size. Hence, there is _currently_ no reason for allowing authors to set borders on buttons. If/when a better mechanism is developed to allow page authors to style buttons widgets, these rules can be reverted (bug 320486).

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

Confirming; this is something we should fix eventually.

How does this play with bug 153572 and bug 310266? Does it improve them, make them worse, or stay the same?

(In reply to comment #8) > How does this play with bug 153572 and bug 310266? Does it improve them, make > them worse, or stay the same? > bug 310266 comment 0 is something I can't reproduce (10.4.8 ppc, trunk). bug 310266 comment 12 (and bug 153572) yes, I've seen it happen, although certainly not often. Definitively not here on bugzilla. When it happens, resizing the window often corrects the problem (forcing a repaint). And as mentioned in bug 153572, that happens way more often with select widgets (dropdown), something I don't touch here. I'll see if a little tweak can help for those select widgets or not, assuming that doesn't cause other problems. bug 153572 comment 15 gives an accurate description: basically, the buttons are too big for their html box (as defined by text-size, borders, padding in forms.css or author styling). They overflow by 1-2 px at the bottom.

For easy testing, add all those rules to your userContent.css

Pushing to 2.0 to revisit in the context of the widget rewrite.

This is vastly improved in the latest trunk widget code; any further tweaks needed should be filed as new bugs in Widget:Cocoa