1385419 - Parent element stretches to submit input's line-height, rather than its also-specified height.

Status: NEW

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

Description

[Thomas Wisniewski]

Attachment: testcase.html

If an input[type=submit] is given both a height and a (much larger) line-height, it will render with the given height, but its parent node will consider it to be as tall as its line-height instead. This leads to the parent being much taller than it should be.

See the attached testcase for a minimal test-case. All other browsers restrict the height of the parent div to the input's actual height, but in Firefox it is as tall as the input's line-height, even though the input isn't actually that tall.

This causes graphical glitches on at least one site which uses a tall line-height to do simple image-replacement (in the "see also" link).

Comment 1

[Astley Chen (inactive)]

Last good revision: 46041cc216fd (2014-03-13)
First bad revision: f073b3d6db1f (2014-03-14)
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=46041cc216fd&tochange=f073b3d6db1f

Comment 2

[Astley Chen (inactive)]

Bug 349259 might the one that we should look at.

Comment 3

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

Attachment: more examples

Comment 4

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

The above testcase seems to show two areas where we do something substantially different from Chrome:
 * input type=button/submit/reset (as in the original testcase here)
 * input type=date/time

Comment 5

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

And Edge expands even fewer lines than Chrome in the testcase:  only textarea (which other browsers don't) and output.  So if we want there's certainly room to drop the expansion from input type=file and type=image without a src.  The only line expanded everywhere is the one for output, which I suspect doesn't have any special layout behavior.

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late to fix for 56, marking fix-optional for 57.

Comment 7

[Karl Dubost💡 :karlcow]

Is this a duplicate of Bug 1246682?

Comment 8

[Karl Dubost💡 :karlcow]

Attachment: Capture d’écran 2017-10-16 à 13.53.46.png

Not sure if it's another issue or related to this but…

https://codepen.io/webcompat/pen/JrmBJL

<input type="submit" value="foobar"/> 
input {line-height: 100px}

This does nothing in 
* Safari Tech Preview Release 41 (Safari 11.1, WebKit 13605.1.8)
* Chrome Version 61.0.3163.100 (Build officiel) (64 bits)


But give the box a size in Firefox Nightly 58.0a1 (2017-10-15) (64-bit)
Not sure who is right there, but there's discrepancy on how we handle this.

If we think we are right I can open bugs on Chromium/WebKit projects.

Found through https://webcompat.com/issues/11860

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 10

[Firefox Bug Husbandry Bot]

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

Comment 11

[Firefox Bug Husbandry Bot]

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

Comment 13

[Thomas Wisniewski [:twisniewski]]

The site reported on webcompat.com has changed their layout a bit and no longer seems to have the issue, so unsetting the webcompat priority for now.