Closed Bug 58662 Opened 24 years ago Closed 23 years ago

Tables grows in width after initial reflow

Categories

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

defect

Tracking

()

VERIFIED WONTFIX
Future

People

(Reporter: peterlubczynski-bugs, Assigned: attinasi)

References

()

Details

(Keywords: testcase)

Attachments

(2 files)

In the URL above, the orange and green tables grown in width when the page is
done loading. Everything looks shifted over. This does not happen with Nav 4.x.

Sometimes, it's really bad. The text area frame moves over the right but the
text stays where it is.

This page has really bad markup with more than one closing <BODY> and <HTML>
tag. However, I don't think that it because I was able to narrow it down to just
a single table.

Perhpas it's something that shouldn't be fixed because it's an ad for MSN.
Attached file simplified testcase
In that testcase, be sure to wait for the throbber to stop to notice the shift.
I am also seeing this on NT, branch build 2000-10-31-14.

-> HTMLTables
Assignee: clayton → karnaze
Component: Layout → HTMLTables
QA Contact: petersen → chrisd
Still seeing this in Mozilla Build 2001012205 Win32.
QA contact update
QA Contact: chrisd → amar
Adding testcase keyword, removing buster from cc.  Still appears, today's Linux
CVS build.
Keywords: testcase
The cell block in the 1st row, 3rd col contains an unloadable image with 
width=20. The cell block reports a max element width=0 during the incremental 
reflow which causes the table to allocate all of the min width of the colspan=2 
cell containing the width=166 image to the 2nd col. Had the cell block in the 
1st row, 3rd col reported a max elem width=20px(300 twips), this would not have 
happened. I removed the width=20 from the image in the 1st row, 3rd col and IE 
displayed the same gap as we do. Also, by putting a width=20 on the containing 
<td>, we remove the gap.

So, it appears that images with width should return max element widths to match 
even if the image is not loaded. Reassigning to attinasi.

Tbl 01193D28 r=1 a=8940,UC c=0,0 cnt=80
 Tbl 01193F04 r=1 a=8940,UC c=UC,UC cnt=81
  RowG 011940F4 r=1 a=3390,UC c=3390,UC cnt=82
   Row 01194274 r=1 a=3390,UC c=3390,UC cnt=83
    Cell 01170550 r=1 a=330,UC c=300,UC cnt=84
     Block 0116FE50 r=1 a=300,UC c=300,UC cnt=85
     Block 0116FE50 d=300,0 me=0 m=0
    Cell 01170550 d=330,60 me=60 m=30
   Row 01194274 d=3390,105
  RowG 011940F4 d=3390,1035
 Tbl 01193F04 d=3420,1065
Tbl 01193D28 d=3420,1065
Assignee: karnaze → attinasi
The problem is with our handling of the image frame when the image is ot found.
We do not honor the width of the image if the image is no loaded, even if there
is ALT text. Attaching a testcase showing how the size of the image frame is not
the specified width in the presence or absence of ALT text, for a missing image.
Status: NEW → ASSIGNED
bug 41924 covers the general ALT-TEXT hanlding problems - marking this as
depending on that.
Depends on: alttext
If both width and height are specified then we honor them in the current trunk
builds. We will not honor the width if the height is not specified by design.

Marking WFM.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Target Milestone: --- → Future
Oops. WONTFIX not WFM
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
WONTFIX
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → WONTFIX
 Marking verified.. Wont fix
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: