User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030718 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030718 I visited gamespot, and found that the abovementioned page displayed incorrectly about 50% of the time. I noted that the right frames were unnaturally stretched out. If you cannot make this bug reuccur, try going back and then clicking on the link in gamespot's main page. Also, the same bug was seen in firebird 0.6 Reproducible: Sometimes Steps to Reproduce: 1.Visit the main page, http://www.gamespot.com/pc/index.html, and click on the link of the abovemetioned game near the bottom 2.If it displays correctly, go back and click again 3. Actual Results: the page reloaded in a weird horizontally stretched out format Expected Results: displayed a proper, framed page theme: modern, and as it is reproduced by firebird with the firebird theme..... Sorry, i am an amateur in this field, just thought to let u guys know, cause i love mozilla.

Happens to me too. The rendering can be correct by clicking back button and forward button again. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030828 Firebird/0.6.1+

Also see this. The sites dont use frames though, changing summary.

This webpage has table rendering problem as well, it can be reproduced every time. http://213.201.218.106/home_startpagina.php Load the page for the first time or shift reload the page will give incorrect rendering, reload or revisit correct the layout. is it the same probem? maybe this can be a new testcase?

confirmed w/ Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030916 complex tables with large in size (or a lot of) images get pre-rendered "wide" and not readjusted when the images are finally loaded. to reproduce it's best to flush cache or use a slower connection.

Comment on attachment 131681 [details] screenshot Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030918 Firebird/0.6.1+

this could be a dublicate of http://bugzilla.mozilla.org/show_bug.cgi?id=217049

More testcases http://www.flexbeta.net - 75% chance of bad rendering http://freshmeat.net - 100% chance(so far) of bad rendering, have to scroll right to see the menu bar

--> changing component and reassigning

this could be a dublicate of 215857

>More testcases >http://www.flexbeta.net - 75% chance of bad rendering >http://freshmeat.net - 100% chance(so far) of bad rendering, have to scroll >right to see the menu bar URL's are not testcases, what is needed here is a reduced testcase as described in http://www.mozilla.org/newlayout/bugathon.html . More general I doubt that in the layout - table component a bug should ever be confirmend without a testcase. With a reduced testcase finding the corresponding dupe will be much more easy.

re Comment #11 , but still this is an isse and should be addressed. It is rather easy to reproduce especially with slow conmnections

>re Comment #11 , but still this is an isse and should be addressed. are you volunteering to fix this?

umm, am I authorized to? I'd be honored if i could help, honestly. And ok I realize that trying to fix a layout problem is tricky.

You are very wellcome to do so. We are allways looking for people who would like to understand the code and fix problems. The first step of fixing a layout problem however is diagnosis what the problem is. A proven way is to eliminate all code that is not nessary to reproduce the problem (aka a reduced testcase). The trick described at http://weblogs.mozillazine.org/hyatt/archives/2003_08.html#003963 might be very helpfull. Then you will need a rock solid knowledge of the html4.01 and CSS2 spec. If you have this you can start debugging where the docs at http://www.mozilla.org/newlayout/doc/ will hopefully serve as a good starting point. C++ knowledge is also necessary at this level. I hope that this does not scare you, even if you could complete the first step it would be very helpfull.

Could it be that this is a duplicate of bug 217004? That one has a testcase written, and it seems to be to do with the time it takes for the page to load. That might explain why reload can fix the problem on some sites (e.g. you are pulling from their 'cache'), but not on others (e.g. Freshmeat.net - maybe they're just under too much load). As a further bit of info, I find that I see this problem on freshmeat.net 100% (even with a shift+refresh), but if I save the page to disk and reload it from then the page renders properly. That suggests to me it is a timing issue. (W2k Firebird 0.7)

hmm, freshmeat loads just fine on my mozilla.....i have a 50% sucess in bug reproduction with it. Another, more popular site in which i see this bug often is Gamespot. It just might me due to the loading time.

It has somethin to do with the loading from internet. Cause It NEVER happens (at least till now) with disk files. But It happen also with fast2load pages, example it happens 70% of the times on the pages loaded from my apache local server, and the loading process is really fast (you don't notice the difference from loading from disk).

*** Bug 221194 has been marked as a duplicate of this bug. ***

After reducing the page from comment #3, I found that it ended up with the same problem as bug 105030, "table does not fit its given width if there is another left-aligned table inside it". Is there an existing bug just for the GameSpot sites?

Is there a way to stop to "on read rendering of pages" ? this should fix the problem since this is how internet explorer and opera render pages. My point is that if firebird reads only one cell out of the table it will render it wrong but if it waits to read the whole table, there won't be a problem. This should explain why it renders it correctly from cache as in bug 215857 which I think is a dublicate of this one

*** Bug 220615 has been marked as a duplicate of this bug. ***

*** Bug 225588 has been marked as a duplicate of this bug. ***

*** Bug 226824 has been marked as a duplicate of this bug. ***

Testcase of the problem. There is an infinite Javascript loop that makes Mozilla bring up the "Stop script?" dialog. If you wait for about 10 seconds before pressing OK, it will lay out the wrong way. If you press the button immediately, it lays out correctly. I don't understand how to use the Javascript trick linked to in comment #15, so if anyone can make this testcase better with that, I encourage you to do so.

Forgot to update an image link. I don't know whether this will work off Bugzilla. It's very sporadic in how it work on my computer. Sometimes it takes a couple tries.

FYI, this bug still occurs in 2003-12-12-09 (after bug 215857 was fixed) Both at http://www.gamespot.com/pc/strategy/korsunpocket/index.html and http://213.201.218.106/home_startpagina.php

Preblem still exists here on http://www.gamespot.com too. using firebird 20031211

*** Bug 228742 has been marked as a duplicate of this bug. ***

In response to comment #21, there is a workaround that's kinda hit and miss but works well with my broadband connection. To simulate on-load rendering, you can increase the value of nglayout.initialpaint.delay to something like 300 (this is in milliseconds) and you will notice that the urls listed in this bug work fine. I'm using Mozilla Firebird 0.7+: Gecko/20031108.

dbaron, can you take a look at this bug and see if there's an easy fix or if it should block 1.6. It's got several duplicates and there appears to be a reduced testcase.

I looked at this a bit a few days ago, but the testcases don't show the problem for me. I did see the problem one time on one of the sites, but that's not useful for debugging it.

Try this testcase. I think the previous one didn't work because it was loading the image from Gamespot. This one loads it locally (you must download the testcase image). When loading it up, you'll get the "A script on this page..." message. Wait 10 seconds or so then press OK. Most of the time, it will show up incorrectly. If you press OK immediately, it will show up correctly. It may take a few tries to get it to work at first.

I still don't see the problem with this testcase.

In case it's of any help, here's another web site with a similar problem. http://www.cyclingnews.com/ Happens both with the Linux and the Windows builds. 90% of the time the right column is too narrow. Forcing a refresh of the page usually fixes it. For what it's worth, I tried it several times and I couldn't see the problem in the original GameSpot link.

Re Comment #35 Try the following url too. http://www.gamespot.com It renders badly almost a 100% of the times Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20031231 Firebird/0.7+ (MozJF)

1.6- for now., renominate if a fix appears in the next few days.

I can confirm this bug in Firebird pre-0.8 [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031231 Firebird/0.7+ (MozJF)], for the original URL, www.gamespot.com, and http://213.201.218.106/home_startpagina.php. Sometimes the problem is visible after a couple of reloads only. No problems with freshmeat.net, though! I can also confirm the problem appearing in testcase #26, although I had to reload that page about 8 times before the problem became apparant.

It seems that this bug happens when there is a lot of images displayed at the same time (for example the little images at the right of a menu's links, for example on gamespot and http://213.201.218.106/home_startpagina.php (see comment 39)). Here is an example with bigger images : http://pirenees.free.fr/paris/paris.html . I think this example could be interesting, because there is a real problem with the "Accueil" word. If you reload the page, there is no problem.

One question. Open xbetas.com in both ie and firebird. In firebird, the top of the page is distorted. Is this related to this bug or is it another one? thanks in advance.

This bug has been there since 1.5a We postponed it to 1.6 and now we want to postpone it to 1.7a again?

The chance that this is going to be fixed without a testcase that developers can use to see the bug is rather low.

David, I can reproduce this testcase every time, also tried it on several computers (with XP). Can it be that its only Windows only? I am no dev, so I have no clue (just guessing now), just think is strange that I can reproduce this every time but some people cant. I use Firebird, seems like most of the dupes also are reported on FB (not all though). Does Mozilla and FB have different paint timeout (Bug 180241)? Does this affect that not everybody is seing this bug?

David: This bug is messing design of Lupa <http://www.lupa.cz/> pretty often and also layout of many tables on several our next servers (Mesec, Slunecnice). Our users also comment rendering problems in Gecko-based browsers, so it's not uncommon.

If you know that those issues are the same bug as this one, could you provide the minimized testcases that you used to figure that out? If not, please don't confuse the bug with issues that are likely to be unrelated.

José Jeria: It isn't only WinXP. I had this bug as well on my Win2K machines. I haven't tested this on any other OSses then Win2k and WinXP. Just a thing that might be helpful: I suspect the html engine makes mistake when a lot of nested tables are used in a big table. I think it closes the first table somewhere in the loading proces of a slow page. When it receives aditional cells or columns, it just add these to the right.

No patch in sight, and we've shipped with this before, so we're not going to hold 1.6 for it.

Re Comment #48 I'm no programmer but, the goal shouldn't be to see if a solution comes by. It should be to develop a fix.

This testcase doesn't require any other files, but downloading it to your hard drive first is still a good idea. I've removed the images and a couple attributes. I see this on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040115 Firebird/0.8.0+ and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040119 Firebird/0.8.0+. Again, it may take a couple times for it to show the behaviour.

Changing OS and Hardware to All. I've tested this on WinXP and Red Hat. If it's not reproducable to any devs, then I'm out of ideas.

Reproducable 100% of the time.

now that we finally have a few reproducible testcases, lets hope that this bug gets resolved quickly. I checked the testcases and found them able to reproduce the bug 100% of the time, with 1.6 and on WinXp, and mandrake linux

This problem doesn't happen all the time. Sometimes the page will be fine but half the time it looks like that.

I've got the same problem with my site. Sometimes the tables aren't displayed as they should. I will try to rewrite my page without the use of <div> frames nested in table cells. Maybe then the bug won't appear!

So what seems to be happening here is that in nsTableRowFrame::ReflowChildren, none of the conditions in the following code is true for the first cell in the last reflow (and the only reflow in which the third cell exists): if ((availCellWidth != cellFrame->GetPriorAvailWidth()) || (cellDesiredSize.width > cellFrame->GetPriorAvailWidth()) || (eReflowReason_StyleChange == aReflowState.reason) || isPaginated || (cellFrame->NeedPass2Reflow() && NS_UNCONSTRAINEDSIZE != aReflowState.availableWidth) || (aReflowState.mFlags.mSpecialHeightReflow && cellFrame->NeedSpecialReflow()) || (!aReflowState.mFlags.mSpecialHeightReflow && cellFrame->HadSpecialReflow()) || HasPctHeight() || notifyStyleChange) { so we end up only reflowing the second cell: rowG 0x9d2e208 r=1 a=3600,UC c=3600,UC cnt=59 row 0x9d2e384 r=1 incr. (Dirty) a=3600,UC c=3600,UC cnt=60 cell 0x9d49d8c r=0 a=UC,UC c=UC,UC cnt=61 block 0x9d49e00 r=0 a=UC,UC c=UC,UC cnt=62 text 0x9d49eac r=0 a=UC,UC c=UC,UC cnt=63 text 0x9d49eac d=480,228 me=480 block 0x9d49e00 d=480,228 me=480 cell 0x9d49d8c d=504,252 me=504 row 0x9d2e384 d=3600,252 o=(0,0) 7656 x 252 rowG 0x9d2e208 d=3600,252 rowG 0x9d2e208 r=2 a=4128,UC c=4128,UC cnt=64 row 0x9d2e384 r=2 a=4128,UC c=4128,UC cnt=65 cell 0x9d49d8c r=2 a=504,UC c=480,UC cnt=66 block 0x9d49e00 r=2 a=480,UC c=480,UC cnt=67 block 0x9d49e00 d=480,228 cell 0x9d49d8c d=504,252 row 0x9d2e384 d=4128,252 rowG 0x9d2e208 d=4128,252 whereas if the DIV has no width specified, we end up with: rowG 0x985c640 r=1 a=3600,UC c=3600,UC cnt=55 row 0x985c7bc r=1 incr. (Dirty) a=3600,UC c=3600,UC cnt=56 cell 0x9878058 r=0 a=UC,UC c=UC,UC cnt=57 block 0x98780cc r=0 a=UC,UC c=UC,UC cnt=58 text 0x9878178 r=0 a=UC,UC c=UC,UC cnt=59 text 0x9878178 d=480,228 me=480 block 0x98780cc d=480,228 me=480 cell 0x9878058 d=504,252 me=504 row 0x985c7bc d=3600,252 o=(0,0) 7656 x 252 rowG 0x985c640 d=3600,252 rowG 0x985c640 r=2 a=3600,UC c=3600,UC cnt=60 row 0x985c7bc r=2 a=3600,UC c=3600,UC cnt=61 cell 0x985c964 r=2 a=1464,UC c=1440,UC cnt=62 block 0x985c9d8 r=2 a=1440,UC c=1440,UC cnt=63 block 0x9877628 r=2 a=1440,UC c=1440,UC cnt=64 block 0x9877628 d=1440,228 block 0x985c9d8 d=1440,228 cell 0x985c964 d=1464,252 cell 0x9878058 r=2 a=2064,UC c=2040,UC cnt=65 block 0x98780cc r=2 a=2040,UC c=2040,UC cnt=66 block 0x98780cc d=2040,228 cell 0x9878058 d=2064,252 row 0x985c7bc d=3600,252 rowG 0x985c640 d=3600,252

The difference between with and without the width on the DIV is that: availCellWidth=1464 cellFrame->GetPriorAvailWidth()=3552 availCellWidth=3552 cellFrame->GetPriorAvailWidth()=3552 (1464 is the size it should end up, roughly; the text is only 528 twips wide)

The problem seems to be coming from nsTableColFrame::GetMinWidth, so it may be related to bug 217527. Because it's returning the old, large, size, BasicTableLayoutStrategy::BalanceColumnWidths decides that the min content width is larger than the available width so no balancing needs to be done.

only drivers can set (+) blocking flags. you can request them (?)

It was set to blocking1.7a? by ht990332@lau.edu.lb before it was set to blocking1.7+ by atahualpa@gmx.at, so I'll set it back to blocking1.7a?.

The first problem is really in the second of the three reflows (the result of the second script): cell 0x8455b6c r=1 a=3552,UC c=3528,UC cnt=40 block 0x8455be0 r=1 a=3528,UC c=3528,UC cnt=41 block 0x8470904 r=1 incr. (Dirty) a=3528,UC c=1440,UC cnt=42 text 0x84709a8 r=2 a=UC,UC c=UC,UC cnt=43 text 0x84709a8 d=528,228 me=480 text 0x847128c r=0 a=UC,UC c=UC,UC cnt=44 text 0x847128c d=0,0 me=0 text 0x84709a8 r=2 a=1440,UC c=UC,UC cnt=45 text 0x84709a8 d=528,228 text 0x847128c r=2 a=912,UC c=UC,UC cnt=46 text 0x847128c d=0,0 block 0x8470904 d=1440,228 me=1440 m=480 block 0x8455be0 d=3528,228 me=3528 m=2568 cell 0x8455b6c d=3552,252 me=3552 m=3552 this suggests this may be a block problem -- brokenness in BRS_COMPUTEMAXWIDTH (which one could argue is inherently broken, but anyway)...

The max width problem looks very similiar to bug 39683, so this might be a very old issue

I have a fix. I just want to clean it up a bit.

This patch fixes the testcase in attachment 139763 [details] (which was reduced, in turn, from the testcase in attachment 139452 [details]). The reflow log also showed that the code at the following location was incorrect, but it doesn't seem to cause any symptoms: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/base/src/nsBlockFrame.cpp&rev=3.602&mark=3171-3172#3166

Comment on attachment 139782 [details] [diff] [review] patch The only real difference that the regression tests showed was that this fixed an incremental reflow bug on table/bugs/bug2479-5.html . The basic idea here is to be consistent about what we do when computing the max-element-width -- don't do different things based on whether the width in the reflow was unconstrained, and recompute the margins since the computed margins have already been adjusted for ignoring the right margin when things are overconstrained.

Fix checked in to trunk, 2004-01-26 21:47 -0800.

Comment on attachment 139960 [details] [diff] [review] a little additional cleanup r+sr=bzbarsky

Bug still not fixed when viewing www.gamespot.com, however all other sites visited are no longer 'deformed'. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040127 Firebird/0.8.0+ (stipe)

my guess is the patch wasn't applied to stipe 20040127 build. I tried scragz 20040127 build, I can't see any problem with gamespot.com anymore! I have been waiting for a long time for this bug to be solved, thanks David for solving this annoying bug =)

> my guess is the patch wasn't applied to stipe 20040127 build. I tried > scragz 20040127 build, I can't see any problem with gamespot.com anymore! Gamespot wfm now, but I just got the same problem with the slashdot comment pages. Using scragz' build #20040128. Can anyone confirm?

Still problems with first loads : http://alainmuchembled.free.fr/fb1.png (link of comment 27) It should be reminded in every {inc} bug that the best way to refresh the page is using the following link (I don't remember where I saw it) : javascript:document.getElementsByTagName("body")[0].style.display='none';document.getElementsByTagName("body")[0].style.display='block';void(0); It is interesting that the above link allows to check if the page has been rendered properly : even if a page seems ok, refreshing with that link may move several elements of a few pixels. That's the case of http://213.201.218.106/home_startpagina.php

Verifying. See bug 232625 for problems http://213.201.218.106/home_startpagina.php . If you continue to have problems with sites other than gamespot, file a new bug.

I'm still seeing this with slashdot (as comment #72). Has someone opened a new bug for that yet?

(In reply to comment #75) > I'm still seeing this with slashdot (as comment #72). Has someone opened a new > bug for that yet? I don't have any problems with slashdot (build ID 2004012808). Where on the site do you have a problem then?

The problem on slashdot may be bug 217527. (But did you read comment 46?)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040128 Firebird/0.8.0+ (scragz) Gamespot now renders corrrecly with this build.

*** Bug 223363 has been marked as a duplicate of this bug. ***

*** Bug 234352 has been marked as a duplicate of this bug. ***

*** Bug 230690 has been marked as a duplicate of this bug. ***

Not sure if this is the same issue, but with a recent nightly again Gamespot.com displays too wide sometimes. Anyone?

(In reply to comment #82) > Not sure if this is the same issue, but with a recent nightly again > Gamespot.com displays too wide sometimes. Anyone? Patrick, I am seing this as well, can you file a new bug for this please? This bug is about another fixed issue.

New bug filed yet?

Has there been any progress on a getting a new bug filed? Or should I open one myself. This is definitely still occuring on FireFox 0.8. Happens at least one out of every 2 visits to the front page. And often times it may take 4-5 refreshes before rendering correctly.

This was fixed well after Firefox 0.8 branched.

Apologies... after dbaron's notification, I downloaded and tried it with Mozilla 1.7a. Gamespot.com does indeed to be working fine now. Thanks, and sorry again.

*** Bug 238462 has been marked as a duplicate of this bug. ***

Question: is this bug fixed in build ID 2004031616 (Mozilla 1.7 beta)? I still get a website that renders its tables incorrect sometimes. (after a refresh it's usually corrected) URL: http://www.luvstruck.com

*** Bug 240145 has been marked as a duplicate of this bug. ***

(In reply to comment #89) Can you please files an new bug about http://www.luvstruck.com and meantion the bug # here?

Ok... I've filed the bug for www.luvstruck.com for Mozilla 1.7beta as bug 240175 .