Tables not displaying right.




Layout: Tables
15 years ago
15 years ago


(Reporter: Stan Noordhuizen, Unassigned)




Firefox Tracking Flags

(Not tracked)




(3 attachments)



15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

The outlining of the tables is wrong. There is a big empty space and using the
scroll bar to go to the right is required. This problem can also be seen on

Reproducible: Always

Steps to Reproduce:
1.go to the mentioned pages

Actual Results:  
layout is wrong

Comment 1

15 years ago
Same thing with the "old" 1.4.1: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.4.1) Gecko/20031008.

Comment 2

15 years ago
1.5 on Linux, seeing this only on the link. Saving the page doesn't
help, so I don't think it's incremental. I'll testcase that one (if no one kicks
me off the computer...)

Is anyone else seeing the problem only on the gamespy link?

Comment 3

15 years ago
Scratch that, it is incremental. 

There's a script referenced at
   var isLoggedIn = false; var adsAreDisabled = false;

I have no idea why that would be forcing a page layout, but apparently it is.

And now I /did/ see the one on gamespot, just once, and it looked incremental,
too. But that's also been noted in bug 221194 and bug 221284.

Comment 4

15 years ago
Assignee: general → table
Component: Browser-General → Layout: Tables
Would be nice to have a minimal testcase....
Keywords: qawanted

Comment 6

15 years ago
Okay, this bug has me confused... It seems to be dependent on some margins being
0, some scripts existing (even if they're just document.write()), other scripts
not only existing but also being linked externally, widths being set through
styles rather than width='x'... remove any of those things and it goes back to
working normally. 

I'm going to keep working on it, see if I can take out any more stuff, but if
anyone wants to see what I have so far, email me or comment here. I don't want
to put it as an attachment 'cause like I said, it still has some externally
referenced files and that's a pain...

OS -> All since I'm on linux

Also, I'm pretty sure the gamespot url in the url field is a different bug than
the, gamespy one (that I've been working on) - maybe just a standard incremental
layout one that's been noted lot's of other places. Should this bug be changed
to only the gamespy one?
OS: Windows XP → All

Comment 7

15 years ago
Created attachment 133957 [details]

Mmmkay, here's a testcase. Note that the two externally referenced scripts
don't have to exist, or they can be blank files. (or you can just have the
source attribute as src='', but then the JS Console complains)

Also note that the original page had the script writing the li's, but the W3C
validator complained about that so I switched them out - the bug stayed the

Comment 8

15 years ago
It had been observed that I can still reproduce this bug when I take out the
following codes in the testcase..

1) <!DOCTYPE ........>
2) <tbody> and </tbody>

Because those two codes can aggravate or produce bugs as it was noticed with the
past bugs in bugzilla, so I checked it out to see if those two are not the cause
and it turned out that they aren't.

Comment 9

15 years ago is bug 217369, so I'm changing the URL here to instead since that has a nice testcase.

All these bugs are probably the same problem anyway... (see the long "blocks"
list on bug 217590)
Depends on: 217590
Ever confirmed: true
Keywords: qawanted → testcase

Comment 10

15 years ago
Web page at:
also does not display correctly

Comment 11

15 years ago
Created attachment 136091 [details]
further reduced testcase

Comment 12

15 years ago
Created attachment 136092 [details]
reflow log

Comment 13

15 years ago
         cell 027197A4 r=1 a=8832,UC c=8784,UC cnt=900 
          block 02719818 r=1 a=8784,UC c=8784,UC cnt=901 
           block 02725A84 r=1 a=8784,UC c=1320,UC cnt=902 
            text 027287E4 r=0 a=UC,UC c=UC,UC cnt=903 
            text 027287E4 d=0,0 me=0 
            text 027287E4 r=2 a=1320,UC c=UC,UC cnt=904 
            text 027287E4 d=0,0 
           block 02725A84 d=1800,96 me=1800 m=480 
           text 02728854 r=0 a=UC,UC c=UC,UC cnt=905 
           text 02728854 d=0,0 me=0 
           text 02728854 r=2 a=8784,UC c=UC,UC cnt=906 
           text 02728854 d=0,0 
          block 02719818 d=8784,480 me=8784 m=7464 
         cell 027197A4 d=8832,528 me=8832 m=8832 

during incr. reflow the block code adds the computed margin to the MEW and
reports a huge MEW, and the table follows that MEW.
Well, weird things happen when we reflow with a constrained width and
simultaneously ask for MEW.  I think many of the bugs that refactoring reflow
would fix come from that case.

Comment 15

15 years ago
Table cells have to incrementally reflow its content with constrained width and
need to be aware of MEW changes. If the MEW changes it might be necessary to
recompute the layout strategy. Another opportunity would of course be to issue a
unconstrained reflow for every incr. reflow but this would be performance desaster.
The table layout takes the "The maximum width and height for elements within the
frame that cannot be broken down further" very literaly, so the MEW should not
include margins that are springy like the left margin in this context. I believe
that everything that goes away when the containing block size shrinks should not
be included in the MEW as the frame can be broken down further if desired. In
this sence this bug goes along the same line as bug 215857.
FYI, this bug still occurs in 2003-12-12-09 (after bug 215857 was fixed)
Both at
All URLs and testcases WFM, 2004-02-02-07 trunk Linux.
Maybe fixed by bug 217369?

Comment 18

15 years ago
yes its a dupe the margins arent now included in the mew.

*** This bug has been marked as a duplicate of 217369 ***
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.