97138 - Heights on tables, row groups, rows, cells do not work correctly

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect, P2)

Description

[karnaze (gone)]

This is a meta bug that groups all bugs that deal with incorrect heights on 
tables, row groups, rows, cells.

Comment 1

[karnaze (gone)]

Attachment: test with table and row height conflicts

Comment 2

[karnaze (gone)]

In the attachment, IE honors the row with height=400 when the table has 
height=200, but does not honor the 2nd row with height=80%. It seems to place 
the constraint that the sum of the percentage rows cannot exceed 100%, but 
places no constraint on pixel valued rows. Is this reasonable, or should the 2nd 
row with height=80% get a full 80% of the table height? If possible, I would 
like to avoid the complicated, ess-efficient balancing that goes on with columns 
where the table width constraint has the highest priority. It appears that IE 
has avoided it as well.

Comment 3

[karnaze (gone)]

Attachment: patch to fix most cases

Comment 4

[Marc Attinasi]

I think you need to initialize the new mBits in the root reflow state
constructor, no? Also, mBits seems like a pretty ambiguous name, why not
something more meaningful like mRefowFlags? Also, please indicate what testing
you have done, which cases it fixes and which it does not fix. Thanks.

Comment 5

[karnaze (gone)]

reassigning to m0.9.6

Comment 6

[karnaze (gone)]

Need to change unsigned to PRUint16 in struct with bitfields (from alexsavulov, 
attinasi).

Comment 7

[karnaze (gone)]

Attachment: more up to date patch with reviewer's suggestions

Comment 8

[karnaze (gone)]

Comment on attachment 56516 [details] [diff] [review]
more up to date patch with reviewer's suggestions

sr=attinasi, r=alexsavulov

Comment 9

[karnaze (gone)]

Attachment: additional patch to be applied after 3rd attachment to fix the test case

Comment 10

[karnaze (gone)]

checked in

Comment 11

[Boris Zbarsky [:bzbarsky]]

This checkin caused bug 109043