14730 - clicking on a dropdown fills the form with white space

Status: VERIFIED DUPLICATE of bug 14694

(Core :: DOM: Core & HTML, defect, P3)

Description

[Yossi Oren]

(PIII running Windows 2K Server build 2031, moz 1999092208)
1. Click "Realplayer G2, Free"
The browser shows a well-formed form with dropdowns for country, OS, etc.
2. Click on the "Select Country"
The form gets filled with whitespace.  On the top of the document there's the
surrounding frame, in the middle the form, all around it whitespace.
View Source shows a lot of blank lines on the top of this page, before the <
html> tag, and a few after it, but these aren't < p> 's, so the browser should
ignore them

Comment 1

[Yossi Oren]

Attachment: simplified page

Comment 2

[karnaze (gone)]

Reassigning to Rod.

Comment 3

[rods (gone)]

Wow this is bad....
Here is a better URL:
http://www.real.com/products/player/downloadrealplayer.html?wp=dl0899&src=990919
choice_1&lang=en

Comment 4

[rods (gone)]

Changing url in url field

Comment 5

[rods (gone)]

I have had no luck reducing this down, but it appears to be a table bug and not
a combobox bug.

Comment 6

[karnaze (gone)]

Troy, the nested table in the attachment is returning a very large max element
height during the incremental reflow which is triggered by activating the combo
box. nsTableFrame::IR_TargetIsChild has the following line which results in the
large value.

  maxElementSize->height += kidMaxElementSize.height;

Instead of "+=" shouldn't it just be "=". I'm reassigning to you since you
recently implemented the setting of max element sizes during incremental reflow.

Comment 7

[troy]

Yes, but I just copied the code that was in PlaceChild(), RecoverState() and
AdjustSiblingsAfterReflow().

If that's what PlaceChild() also does, then why don't we have this problem on
the initial reflow as well?

I agree that it probably should be '=' instead of '+=', but why does anyone
care? I thought the max element height wasn't used?

Comment 8

[troy]

This is one of the isses we need to go over when we code review the table code.
It seems that BalanceColumnWidths() also computes the max-element-size, although
I don't think it computes it correctly. I ran into this issue when changing
tables to calculate max-element-size during incremental reflow.

After adding code to compute it the usual way I was surprised to see that
BalanceColumnWidths() was computing it.

Comment 9

[troy]

I guess PlaceChild() is wrong as well, but we would only see problems in a table
that has multiple row group frames

Comment 10

[troy]

*** This bug has been marked as a duplicate of 14694 ***