403558 - 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)

Status: NEW

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

Description

[(not reading, please use [e-mail] instead)]

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.

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: test case

Comment 2

[(not reading, please use [e-mail] instead)]

Attachment: 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

Comment 3

[(not reading, please use [e-mail] instead)]

since fx 2 and fx 3 are different, adding regression keyword

Comment 4

[philippe (part-time)]

Attachment: 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).

Comment 5

[(not reading, please use [e-mail] instead)]

Attachment: screen shot of test case in opera 9.24, IE 7, Fx 3 and then Fx 2

Comment 6

[(not reading, please use [e-mail] instead)]

I've run into the same problem again (but with a different form control) on paypal.

Comment 7

[(not reading, please use [e-mail] instead)]

Attachment: screen shot from paypal

Comment 9

[Boris Zbarsky [:bzbarsky]]

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.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

How would that help here?  In this case the height is not auto...

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 13

[Boris Zbarsky [:bzbarsky]]

We don't set a minimum widget size for text controls at all.

Comment 14

[Damon Sicore (:damons)]

dbaron, boris:  Thoughts on blocking 1.9.1 here?

Comment 15

[Boris Zbarsky [:bzbarsky]]

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...

Comment 16

[Benjamin Smedberg]

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?

Comment 17

[Boris Zbarsky [:bzbarsky]]

Let's start with Mac, since that's what the bug is filed on.  We might need a separate bug for Linux.

Comment 18

[Emil Pasca [:emilpasca]]

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.