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

RESOLVED FIXED in mozilla0.9.6

Status

()

Core
Layout: Tables
P2
major
RESOLVED FIXED
17 years ago
16 years ago

People

(Reporter: karnaze (gone), Assigned: karnaze (gone))

Tracking

({testcase})

Trunk
mozilla0.9.6
x86
Windows NT
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: PATCH CANDIDATE_094)

Attachments

(4 attachments)

(Assignee)

Description

17 years ago
This is a meta bug that groups all bugs that deal with incorrect heights on 
tables, row groups, rows, cells.
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.5

Updated

17 years ago
Depends on: 58402

Updated

17 years ago
Depends on: 51000

Updated

17 years ago
Depends on: 87982
(Assignee)

Updated

17 years ago
Depends on: 30692
(Assignee)

Comment 1

17 years ago
Created attachment 47491 [details]
test with table and row height conflicts

Updated

17 years ago
Depends on: 57300

Updated

17 years ago
Depends on: 88035
(Assignee)

Comment 2

17 years ago
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.

Updated

17 years ago
Depends on: 42543
(Assignee)

Updated

17 years ago
Depends on: 32205, 55202

Updated

16 years ago
Depends on: 98196

Updated

16 years ago
Keywords: testcase
(Assignee)

Comment 3

16 years ago
Created attachment 49585 [details] [diff] [review]
patch to fix most cases
(Assignee)

Updated

16 years ago
Keywords: patch

Comment 4

16 years ago
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.
(Assignee)

Comment 5

16 years ago
reassigning to m0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
(Assignee)

Updated

16 years ago
Blocks: 32451
(Assignee)

Updated

16 years ago
Keywords: patch
Whiteboard: PATCH
(Assignee)

Comment 6

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

Comment 7

16 years ago
Created attachment 56516 [details] [diff] [review]
more up to date patch with reviewer's suggestions
(Assignee)

Comment 8

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

sr=attinasi, r=alexsavulov
Attachment #56516 - Flags: superreview+
Attachment #56516 - Flags: review+
(Assignee)

Comment 9

16 years ago
Created attachment 56526 [details] [diff] [review]
additional patch to be applied after 3rd attachment to fix the test case
(Assignee)

Updated

16 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Priority: -- → P2
Resolution: --- → FIXED
Whiteboard: PATCH → PATCH CANDIDATE_094
(Assignee)

Comment 10

16 years ago
checked in
(Assignee)

Updated

16 years ago
Blocks: 106795
This checkin caused bug 109043
(Assignee)

Updated

16 years ago
Blocks: 32205
No longer depends on: 32205
You need to log in before you can comment on or make changes to this bug.