223363 - Tables not displaying right.

Status: RESOLVED DUPLICATE of bug 217369

(Core :: Layout: Tables, defect)

Description

[Stan Noordhuizen]

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
http://www.gamespy.com/games/release/ps2/

Reproducible: Always

Steps to Reproduce:
1.go to the mentioned pages
2.
3.

Actual Results:  
layout is wrong

Comment 1

[Giovanni Mariani]

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

[dolphinling]

1.5 on Linux, seeing this only on the gamespy.com 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

[dolphinling]

Scratch that, it is incremental. 

There's a script referenced at http://ads.gamespyid.com/jscheck.aspx:
   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

[Bill Mason]

->Layout:Tables

Comment 5

[Boris Zbarsky [:bzbarsky]]

Would be nice to have a minimal testcase....

Comment 6

[dolphinling]

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?

Comment 7

[dolphinling]

Attachment: testcase

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
same.

Comment 8

[Zook Valem]

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

[Mats Palmgren (inactive)]

http://www.gamespot.com is bug 217369, so I'm changing the URL here to
http://www.gamespy.com/games/release/ps2/ instead since that has a nice testcase.

All these bugs are probably the same problem anyway... (see the long "blocks"
list on bug 217590)

Comment 10

[J]

Web page at:
http://www.webstrider.com/computer/
also does not display correctly
J

Comment 11

[Bernd]

Attachment: further reduced testcase

Comment 12

[Bernd]

Attachment: reflow log

Comment 13

[Bernd]

         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.

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Bernd]

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.

Comment 16

[Mats Palmgren (inactive)]

FYI, this bug still occurs in 2003-12-12-09 (after bug 215857 was fixed)
Both at http://www.gamespy.com/games/release/ps2/
and     http://www.webstrider.com/computer/

Comment 17

[Mats Palmgren (inactive)]

All URLs and testcases WFM, 2004-02-02-07 trunk Linux.
Maybe fixed by bug 217369?

Comment 18

[Bernd]

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

*** This bug has been marked as a duplicate of 217369 ***