text in input (with font-size and height specified) is more cropped in Fx 3 than in Fx 2 (and Safari isn't cropped at all)




Widget: Cocoa
11 years ago
2 years ago


(Reporter: (not reading, please use seth@sspitzer.org instead), Unassigned)


({polish, regression})

polish, regression
Bug Flags:
blocking1.9.2 -
wanted1.9.2 +
blocking1.9.1 -
wanted1.9.1 -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: tpi:+, URL)


(5 attachments)

text in input (with font-size and height specified) is more cropped in Fx 3 than in Fx 2 (and Safari isn't cropped at all)

I'll attach a screen shot and a simplified test case.

I found this in the wild at weddingchannel.com during the checkout process.
Created attachment 288410 [details]
safari on the left, fx 2009 in the middle, trunk on the right

trunk is Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2pre) Gecko/2007111215 Minefield/3.0b2pre
since fx 2 and fx 3 are different, adding regression keyword
Keywords: regression
Component: General → General
Keywords: qawanted
Product: Firefox → Core
QA Contact: general → general

Comment 4

11 years ago
Created attachment 288444 [details]
Safari 3.03beta

Safari 3.03beta and latest Webkit builds /OS X 10.4.10 are also clipping the text.

(Safari 2.04 did not support the height property for form controls).
Created attachment 288446 [details]
screen shot of test case in opera 9.24, IE 7, Fx 3 and then Fx 2
I've run into the same problem again (but with a different form control) on paypal.
Created attachment 290356 [details]
screen shot from paypal
So this regressed with the native theme stuff on Mac and Linux, at least.  We have _much_ bigger internal paddings now, and those are causing serious problems here.

Should we be dropping native theming for non-auto-height text inputs, perhaps?  Or somehow reducing the native theme padding when there's just no space for it?  This makes sits much harder to use.  I've run into it a bunch but always just chalked it up to a buggy site... except that it seems they're only slightly buggy.
Flags: blocking1.9.1?
Keywords: qawanted
Alternatively (and in my opinion, preferably), we could fix bug 369581.  I suspect this would, in the large, make sites more usable, but sometimes cause gaps or overlapping.
How would that help here?  In this case the height is not auto...
There might be other issues; I'd thought GetMinimumWidgetSize was honored for non-auto heights, but maybe it's not, or maybe we're not setting appropriate values in the widget code.
We don't set a minimum widget size for text controls at all.
dbaron, boris:  Thoughts on blocking 1.9.1 here?
At this point, I'm not sure it should block.  I think we definitely need to fix this stuff, along with various other issues native theming is causing in 1.9.next...


10 years ago
OS: Mac OS X → All

Comment 16

10 years ago
Seems to me that this ought to move out of core/general. Is there a more specific layout or native-theming component it could live in?
Flags: wanted1.9.1-
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Let's start with Mac, since that's what the bug is filed on.  We might need a separate bug for Linux.
Assignee: nobody → joshmoz
Component: General → Widget: Cocoa
Flags: blocking1.9.2?
QA Contact: general → cocoa


9 years ago
Assignee: joshmoz → nobody


9 years ago
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: blocking1.9.2-
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:50.0) Gecko/20100101 Firefox/50.0

I have tested this issue on Mac OS X 10.11 with the latest Firefox release (47.0) and the latest Nightly (50.0a1-20160617030217) and is still reproducible.
After opening the test case, you can observe that the text from the input filed is cropped.
The same behavior appears in Chrome as well but in Safari, the text is displayed correctly.


2 years ago
Keywords: polish
Priority: -- → P3


2 years ago
Whiteboard: tpi:+
You need to log in before you can comment on or make changes to this bug.