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
•