cells in a table get messed up when placing the table into two nested, absolute positioned DIVs

RESOLVED FIXED

Status

()

RESOLVED FIXED
16 years ago
14 years ago

People

(Reporter: semmel, Assigned: mats)

Tracking

({testcase})

Trunk
x86
Linux
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

The horizontal cell alignment doesn't work if you place the table into two
nested, absolute positioned DIVs.

example code:

<style type="text/css">
div {position:absolute;}
td {border-width:1px;border-style:solid;}
</style>
<body>
<div>
<div>
<table>
<tr><td>hier steht was</td><td>hier auch</td><td>und hier nochmal</td></tr>
<tr><td>links</td><td>mitte</td><td>rechts</td></tr>
</table>
</div>
</div>
</body>


Reproducible: Always

Steps to Reproduce:
At a guess, the table is optimizing away something it should not.... Bernd, any
idea where I would look to get a good idea of what's happening?

Comment 2

16 years ago
Created attachment 119686 [details]
testcase

Comment 3

16 years ago
Boris sorry but I can not resist: if all else fails may be you should read the
manual. ;-)
http://lxr.mozilla.org/seamonkey/source/layout/doc/frame_reflow_debug.html

Comment 4

16 years ago
Created attachment 119689 [details]
reflow log

It looks like the table is missing the second resize reflow. My blind guess is
around
http://lxr.mozilla.org/seamonkey/source/layout/html/table/src/nsTableFrame.cpp#2047

Comment 5

16 years ago
and unconstrained resize reflows - tables dont like them, I thought that should
never happen.

Comment 6

16 years ago
Created attachment 119696 [details]
ref. testcase with a single div

Comment 7

16 years ago
Created attachment 119699 [details]
ref. reflow log

from the previous reflow log
initial reflow

area 025EDE30 r=0 a=UC,UC c=UC,UC cnt=860 

resize reflow

area 025EDE30 r=2 a=UC,UC c=UC,UC cnt=895 

Ok I can understand that frames that shrink wrap dont know how large will be
the area, so they make a unconstrained initial reflow. But after this reflow
they should know the size and not issue a unconstrained resize reflow. For me
that translates like: ehm I changed my size from unknown to unknown, what a
difference and now please children guess how large I am.

Comment 8

16 years ago
the block reflow is totally horked for the two div case and why four reflows are
necessary in the one div case also seems to be a mystery
Assignee: table → block-and-inline
Status: UNCONFIRMED → NEW
Component: Layout: Tables → Layout: Block & Inline
Ever confirmed: true
QA Contact: madhur → ian

Comment 9

16 years ago
*** Bug 207675 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

14 years ago
Assignee: core.layout.block-and-inline → mats.palmgren
Depends on: 201897
Keywords: testcase
(Assignee)

Comment 10

14 years ago
-> FIXED (by bug 201897)
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
(Assignee)

Comment 11

14 years ago
*** Bug 276974 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.