Open
Bug 805593
Opened 12 years ago
Updated 2 years ago
Inconsistent button rendering at different sizes in OSX
Categories
(Core :: Widget: Cocoa, defect, P4)
Tracking
()
NEW
People
(Reporter: mozilla.org, Unassigned)
Details
(Whiteboard: tpi:+)
Attachments
(1 file)
191.88 KB,
image/png
|
Details |
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.
![]() |
||
Updated•12 years ago
|
Summary: Inconsitent button rendering at different sizes in OSX → Inconsistent button rendering at different sizes in OSX
Updated•12 years ago
|
Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
![]() |
||
Comment 1•12 years ago
|
||
Not a DOM issue. This looks like a matter of native widget styling....
Component: DOM: Core & HTML → Widget: Cocoa
![]() |
||
Comment 2•12 years ago
|
||
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•12 years ago
|
||
Is this a recent regression? Does it happen with older versions of Firefox?
Comment 4•12 years ago
|
||
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•12 years ago
|
||
So this bug goes back to the patch for bug 418497.
Updated•12 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 6•12 years ago
|
||
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.
Reporter | ||
Comment 7•12 years ago
|
||
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•10 years ago
|
||
Confirming this is still an issue in latest builds.
Comment 9•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
(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•10 years ago
|
||
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•10 years ago
|
||
Thanks! So, given that we do the same as Safari and Chrome here, I don't see the need to change anything.
Comment 16•10 years ago
|
||
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•10 years ago
|
||
Here's a try build with NSShadowlessSquareBezelStyle replaced by NSTexturedSquareBezelStyle: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/mstange@themasta.com-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•10 years ago
|
||
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.
Updated•8 years ago
|
Whiteboard: tpi:p3
![]() |
||
Updated•8 years ago
|
Priority: -- → P2
Whiteboard: tpi:p3 → tpi:+
Updated•8 years ago
|
Priority: P2 → P4
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•