Closed
Bug 58662
Opened 24 years ago
Closed 23 years ago
Tables grows in width after initial reflow
Categories
(Core :: Layout: Tables, defect, P3)
Core
Layout: Tables
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.
|
Reporter | |
Comment 1•24 years ago
|
||
|
|
Reporter | |
Comment 2•24 years ago
|
||
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
|
||
Comment 4•24 years ago
|
||
Still seeing this in Mozilla Build 2001012205 Win32.
|
||
Comment 6•23 years ago
|
||
Adding testcase keyword, removing buster from cc. Still appears, today's Linux
CVS build.
Keywords: testcase
|
||
Comment 7•23 years ago
|
||
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
|
Assignee | |
Comment 8•23 years ago
|
||
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
|
|
Assignee | |
Comment 9•23 years ago
|
||
|
|
Assignee | |
Comment 10•23 years ago
|
||
bug 41924 covers the general ALT-TEXT hanlding problems - marking this as
depending on that.
Depends on: alttext
|
||
Comment 11•23 years ago
|
||
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
|
|
||
Comment 12•23 years ago
|
||
Oops. WONTFIX not WFM
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
|
|
||
Comment 13•23 years ago
|
||
WONTFIX
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•