All users were logged out of Bugzilla on October 13th, 2018
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.
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.
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
Created attachment 52565 [details] testcase showing how the image width is ignored if the image is not found
bug 41924 covers the general ALT-TEXT hanlding problems - marking this as depending on that.
Depends on: 41924
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
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Target Milestone: --- → Future
Oops. WONTFIX not WFM
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago → 17 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.