805593 - Inconsistent button rendering at different sizes in OSX

Status: NEW

(Core :: Widget: Cocoa, defect, P4)

Description

[Mihail Milushev]

Attachment: Screen Shot 2012-10-25 at 16.09.06.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4

Steps to reproduce:

Create a HTML5 page with the following snippet:

  <input style="height: 26px" type="button">
  <input style="height: 27px" type="button">

http://jsbin.com/ugonid/1/edit


Actual results:

The two buttons have vastly different appearances: the 26px one has kind-of rounded corners and somewhat distorted shape; the 27px one has square corners and a different background. While the 27px one is truly 27px tall, the 26px one is hard to measure due to blurry border; still, no matter how measured, it is at most 25px tall.


Expected results:

All other browsers render visually similar buttons at both sizes. Opera renders similar buttons and delivers exactly the requested heights. Webkit browsers disregard the height at all (additional hacks are needed to break them out of rendering system buttons and get them to start following the styles), but they're still visually similar.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Not a DOM issue.  This looks like a matter of native widget styling....

Comment 2

[Boris Zbarsky [:bzbarsky]]

And in particular, we have to make tradeoffs between the OS look and the styles, especially when the OS look doesn't actually support the styles you asked for.

You can, of course, turn off native theming altogether if you don't want it...

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Is this a recent regression?  Does it happen with older versions of Firefox?

Comment 4

[Stefan [:stefanh]]

Looks like we start drawing "square" buttons at 27px height. This is from nsNativeThemeCocoa.mm:

912 // The height at which we start doing square buttons instead of rounded buttons
913 // Rounded buttons look bad if drawn at a height greater than 26, so at that point
914 // we switch over to doing square buttons which looks fine at any size.
915 #define DO_SQUARE_BUTTON_HEIGHT 26

Comment 5

[Steven Michaud [:smichaud] (Retired)]

So this bug goes back to the patch for bug 418497.

Comment 6

[Mihail Milushev]

I would say rounded buttons start looking bad at _every_ height above 20px, which apparently is the native height of push buttons in Cocoa; even at 21px, the button looks very blurry and strangely enough grows a bit _sideways_. As for smaller heights, 19px looks exactly the same as 20px; 18px looks _very_ blurry, while 17px is probably the native height for "small" buttons and looks arguably good. Heights smaller than 17px have no effect whatsoever.

If this behavior is a tradeoff, it is the most useless tradeoff ever. _No_ "kind-of-native" size looks any good, except for 17px, 19px and 20px. I'd say it would be much better to only render native buttons at 20px, and square buttons at any other height.

Comment 7

[Mihail Milushev]

And the invalid style "height: -1px", instead of being ignored, results in a very weird rendering, the only height that results in an actual height smaller than the 17px limit.

Comment 8

[Michael Newton]

Confirming this is still an issue in latest builds.

Comment 9

[Markus Stange [:mstange] (back Aug 27)]

Any ideas on what we should do instead? As far as I know, the blurriness problem for in-between states has been fixed in the meantime.

Comment 10

[Michael Newton]

Personally, I can't see any situation where a page author (or user) would want two different button styles on the page. In a case where the author may not be able to control the height of the button due to wrapping text, it can be quite ugly: http://imgur.com/6Ynnuld

I'd suggest just getting rid of the square buttons and sticking with the native-looking ones.

Note also that just changing the background colour of the button results in really ugly 1996-looking buttons. Likely unrelated but thought I'd mention it.

Comment 11

[Markus Stange [:mstange] (back Aug 27)]

The problem is that OS X doesn't know how to draw the regular button style with higher buttons. So when the text wraps, what button style should we draw?

Comment 12

[Michael Newton]

Got it; I misread your comment about blurriness being fixed as being able to draw any height. I guess setting DO_SQUARE_BUTTON_HEIGHT to 0 seems most logical, but could be too radical a change for the user experience. I guess that's the dilemma that's been keeping this bug here for a couple of years.

What about a NSTexturedSquareBezelStyle button (he says, trying to sound like a real programmer) which can be set to an arbitrary height and looks similar to a standard NSRoundedBezelStyle button?

Comment 13

[Markus Stange [:mstange] (back Aug 27)]

(In reply to Michael Newton from comment #12)
> Got it; I misread your comment about blurriness being fixed as being able to
> draw any height. I guess setting DO_SQUARE_BUTTON_HEIGHT to 0 seems most
> logical, but could be too radical a change for the user experience. I guess
> that's the dilemma that's been keeping this bug here for a couple of years.

Correct.

> What about a NSTexturedSquareBezelStyle button (he says, trying to sound
> like a real programmer) which can be set to an arbitrary height and looks
> similar to a standard NSRoundedBezelStyle button?

Seems reasonable - does it look okay-ish on all versions of OS X?

As far as I know, the reason we went for NSShadowlessSquareBezelStyle was that that was Safari was doing at the time. But since Safari doesn't really let you change the height of the button (except through font size), the tradeoffs it has to make are different.

Comment 14

[Michael Newton]

On Mavericks it looks exactly like a standard button, but on Yosemite there is no border. I would hope that adding a border to a button would be a simple process, but have no idea.

https://mackuba.eu/2014/10/06/a-guide-to-nsbutton-styles/#textured

Safari is still doing the same thing, reverting to NSShadowlessSquareBezelStyle where the button text wraps. Same behaviour in Chrome. So at least everyone's in agreement, but I'm really surprised Apple hasn't addressed this in their API.

Comment 15

[Markus Stange [:mstange] (back Aug 27)]

Thanks! So, given that we do the same as Safari and Chrome here, I don't see the need to change anything.

Comment 16

[Michael Newton]

The fact that it's the same thing Safari and Chrome do, doesn't make it any less ugly when two vastly different buttons are placed side by side just because of the length of text in them.

I'm not a C++ programmer, but I can open a file and replace NSShadowlessSquareBezelStyle with NSTexturedSquareBezelStyle, so will give it a shot when I have some extra time this week to set up a build on my MacBook.

And I know this is just a cosmetic issue, but as a user of Firefox since it forked from Mozilla many years ago, I would hate to think that you guys are now using the limitations of the competition to define the extent of your project.

Comment 17

[Markus Stange [:mstange] (back Aug 27)]

Here's a try build with NSShadowlessSquareBezelStyle replaced by NSTexturedSquareBezelStyle:
https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-5ea1703437b0/try-macosx64/firefox-40.0a1.en-US.mac.dmg

I think the most useful thing you could do here is to take some screenshots of before / after, with different backgrounds on versions of OS X, so that our UX people can make the decision whether we should make that change.

Comment 18

[Michael Newton]

It's not usable with a simple swap, unfortunately. Without the border around the button there's not enough contrast between it and the content. I tried adding [cell setBordered:YES] as well but it didn't have any effect.

Given that the appearance of a "native" button seems tenuous (an unstyled button looks exactly like an OS X button, but just changing the background colour reverts to an old 90s-style button) is this something that could be fixed by changing the default browser CSS?

I do think this bug should remain open, even if there's no means right now to fix it. In the meantime, I'll be sure to style my web pages' buttons to death, to make sure I avoid the native buttons.