All users were logged out of Bugzilla on October 13th, 2018

Tables grows in width after initial reflow

VERIFIED WONTFIX

Status

()

P3
normal
VERIFIED WONTFIX
18 years ago
17 years ago

People

(Reporter: peterlubczynski-bugs, Assigned: attinasi)

Tracking

(Depends on: 1 bug, {testcase})

Trunk
Future
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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

18 years ago
Created attachment 18413 [details]
simplified testcase
(Reporter)

Comment 2

18 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

18 years ago
Still seeing this in Mozilla Build 2001012205 Win32.

Comment 5

18 years ago
QA contact update
QA Contact: chrisd → amar
Adding testcase keyword, removing buster from cc.  Still appears, today's Linux
CVS build.
Keywords: testcase

Comment 7

17 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

17 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

17 years ago
Created attachment 52565 [details]
testcase showing how the image width is ignored if the image is not found
(Assignee)

Comment 10

17 years ago
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 → ---
WONTFIX
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → WONTFIX

Comment 14

17 years ago
 Marking verified.. Wont fix
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.