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
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.
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?
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.
Assignee: general → table
Component: Browser-General → Layout: Tables
Would be nice to have a minimal testcase....
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
Created attachment 133957 [details] 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.
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.
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)
Web page at: http://www.webstrider.com/computer/ also does not display correctly J
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.
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 http://www.gamespy.com/games/release/ps2/ and http://www.webstrider.com/computer/
All URLs and testcases WFM, 2004-02-02-07 trunk Linux. Maybe fixed by bug 217369?
yes its a dupe the margins arent now included in the mew. *** This bug has been marked as a duplicate of 217369 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.