1541964 - Input with line-height: 1 may cut off parts of the text, unlike Blink.

Status: RESOLVED DUPLICATE of bug 1623124

(Core :: Layout: Form Controls, defect, P3)

Description

[Thomas Wisniewski [:twisniewski]]

Attachment: testcase.html

In the simple attached test-case, an input has its default padding and border removed, and the results are the the text's descenders do not always fit in the box (dependent on font-size/zoom level, and presumably the font itself).

It appears as though Blink makes the input tall enough to fit its text's descenders, while Firefox seems to rely on the border and/or padding to ensure that the input will be tall enough to completely show the text.

This is ultimately causing the inputs in this webcompat issue to appear cut off: https://webcompat.com/issues/28810

Comment 1

[Emilio Cobos Álvarez (:emilio)]

There is already a line-height hack for <input>: https://searchfox.org/mozilla-central/rev/9ee63566281365f26e7a4b06c9d4e2219e64c3e8/layout/generic/ReflowInput.cpp#2903

This was added in bug 349259. Maybe we do need to increase that limit a bit to be "at least normal"? May be worth checking what Chrome and WebKit are doing...

Comment 2

[Emilio Cobos Álvarez (:emilio)]

This doesn't have to do with margin / border though, at least the following repros for me too on linux: data:text/html,<input style="line-height: 1; font-size: 50px">.

Comment 3

[Mats Palmgren (inactive)]

Make the floor 1.2 and declare victory?

Comment 4

[Emilio Cobos Álvarez (:emilio)]

This is the Blink version of the hack:

https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/forms/text_control_inner_elements.cc?l=175&rcl=9c25a970bb13a707bc4c5de5eaef6d4662a5eb90

So what they use is roughly: if (fontSize >= lineHeight) lineHeight = normal;

Which is a bit silly, since that means that in my example, with line-height: 1.05 you get an smaller line-height than with line-height: 1, which makes no sense.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Wow, and I thought that the Gecko hack was bad. That whole function is a mess.

Comment 6

[Thomas Wisniewski [:twisniewski]]

I wonder if that just means this is a good opportunity to try to standardize something with this behavior? :)

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Sure, the "what" is the hard part...

Comment 8

[Mats Palmgren (inactive)]

Perhaps max(resolved computed line-height, resolved 'line-height:normal')
would be acceptable to everyone?

Standardizing 'normal' might be trickier, so the above avoids that issue...
https://github.com/w3c/csswg-drafts/issues/3749

Comment 9

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 10

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 11

[Ksenia Berezina [:ksenia]]

The linked webcompat issue has been fixed. The issue in the testcase is no longer reproducible either.

mozregression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7c83f04c82e9ef6c1d2823a64aedd34a79a90eb9&tochange=737aba43bfa1685fa15a9b542636b959397603a8

Looks like bug 1623124 might have fixed this.