78066 - empty 'vertical-align: bottom' input has extra space below on first reflow

Status: RESOLVED WORKSFORME

(Core :: Layout: Block and Inline, defect, P4)

Description

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

DESCRIPTION:  An empty text input alone in a table cell but followed by
whitespace in quirks has extra space below it until one types in the input box,
and then the space is reduced.

STEPS TO REPRODUCE:
 * load testcase (or load http://my.netscape.com/ and go to "Login")
 * Type in text input

ACTUAL RESULTS:
 * text below it moves up

EXPECTED RESULTS:
 * no movement outside the box

Comment 1

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

Attachment: testcase

Comment 2

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

*** Bug 82114 has been marked as a duplicate of this bug. ***

Comment 3

[doctor__j]

*** Bug 82731 has been marked as a duplicate of this bug. ***

Comment 4

[doctor__j]

*** Bug 84437 has been marked as a duplicate of this bug. ***

Comment 5

[doctor__j]

*** Bug 85056 has been marked as a duplicate of this bug. ***

Comment 6

[doctor__j]

*** Bug 85268 has been marked as a duplicate of this bug. ***

Comment 7

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

Attachment: another interesting testcase

Comment 8

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

Attachment: another interesting testcase (right mime type this time!)

Comment 9

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

I investigated this a bit (since I originally thought it was a bug in line 
layout), and I'm beginning to get an idea what's going on here.  Here's what 
I'm seeing:

 * the text input, according to forms.css, has 'vertical-align: bottom'.  I 
filed bug 87981 on this issue alone.

 * When we have whitespace after the text input, this whitespace gets its 
zeroEffectiveSpanBox flag set in line layout, since it's an "empty" text 
frame.  This means it is set to have a height of zero and ascent and descent of 
0 for purposes of vertical alignment.  (See bug 5821 and bug 24186.)

 * Tables expand themselves for inline content that overflows its line box, 
which I think is incorrect (bug 87982).

The combination of the zeroEffectiveSpanBox being set and the 'vertical-align: 
bottom' means that the bottom of the text input is aligned with the bottom of 
the otherwise zero-height line so that the descenders of the text overflow the 
bottom of the line.

So my theory is that the code that determines what overflow the table is seeing 
is counting the empty text node that line layout gave zero height as 
overflowing the bottom of its block and therefore expanding the table cell to 
contain it.  What I don't understand yet is why this space goes away after 
typing.

Comment 10

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

One reason this might happen only when the input is empty is that the code to
implement bug 87982 might itself be buggy.  I should find that code...

Comment 11

[Vladimir Ermakov]

*** Bug 88606 has been marked as a duplicate of this bug. ***

Comment 12

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

*** Bug 86322 has been marked as a duplicate of this bug. ***

Comment 13

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

Checked in fix for bug 87981 to trunk on 2001-07-12 22:19 PDT.  That change
should cover up this problem and is good in itself, although the other bugs
needed to cause the problem still exist.

Comment 14

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

Moving off since it's not a major problem anymore.

Comment 15

[Andreas Kunz]

dbaron:
In comment #9 you mentioned several bugs causing this as a combined result.
All of them are fixed now (thereby fixing this bug as reported), except for bug
87982. But that one also looks like WFM, so there seems to be nothing left for
this report to be resolved.

Comment 16

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

The testcase needs to be changed for at least two reasons:
 * inputs are now reflow roots
 * explicit 'vertical-align: bottom' is required

The underlying bug may still exist.

Comment 17

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

The weird initial alignment when 'vertical-align: bottom' was present went away
between 1.0.2 and 1.1.