Last Comment Bug 217369 - {inc} pages sometimes too wide/messed up on first load
: {inc} pages sometimes too wide/messed up on first load
: testcase
Product: Core
Classification: Components
Component: Layout: Tables (show other bugs)
: Trunk
: All All
P1 normal with 20 votes (vote)
: mozilla1.7alpha
Assigned To: David Baron :dbaron: ⌚️UTC-8
: Madhur Bhatia
: 220615 221194 223363 225588 226824 228742 230690 234352 238462 240145 (view as bug list)
Depends on: 215857 217590
Blocks: 200047
  Show dependency treegraph
Reported: 2003-08-26 13:07 PDT by Aditya N
Modified: 2004-05-09 12:04 PDT (History)
31 users (show)
dbaron: blocking1.6-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

screenshot (269.92 KB, image/jpeg)
2003-09-18 09:49 PDT, ktml
no flags Details
testcase (4.84 KB, text/html)
2003-11-27 20:56 PST, Jason Barnabe (np)
no flags Details
testcase (7.22 KB, text/html)
2003-11-27 21:04 PST, Jason Barnabe (np)
no flags Details
testcase image (381 bytes, image/gif)
2003-12-19 12:38 PST, Jason Barnabe (np)
no flags Details
testcase (3.85 KB, text/html)
2003-12-19 12:41 PST, Jason Barnabe (np)
no flags Details
new testcase (2.95 KB, text/html)
2004-01-19 15:59 PST, Jason Barnabe (np)
no flags Details
simplified testcase (430 bytes, text/html; charset=UTF-8)
2004-01-19 21:38 PST, David Baron :dbaron: ⌚️UTC-8
no flags Details
screenshot (172.69 KB, image/jpeg)
2004-01-21 07:09 PST, Eric Price
no flags Details
testcase (429 bytes, text/html; charset=UTF-8)
2004-01-23 16:04 PST, David Baron :dbaron: ⌚️UTC-8
no flags Details
patch (2.89 KB, patch)
2004-01-23 23:20 PST, David Baron :dbaron: ⌚️UTC-8
roc: review+
roc: superreview+
Details | Diff | Splinter Review
a little additional cleanup (3.89 KB, patch)
2004-01-26 22:22 PST, David Baron :dbaron: ⌚️UTC-8
bzbarsky: review+
bzbarsky: superreview+
Details | Diff | Splinter Review
Screenshot of with Moz 2004030409 on XP Pro (268.27 KB, image/jpeg)
2004-03-08 10:52 PST, Patrick
no flags Details

Description User image Aditya N 2003-08-26 13:07:23 PDT
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,, and click on the
link of the abovemetioned game near the bottom
2.If it displays correctly, go back and click again

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.
Comment 1 User image ktml 2003-08-30 17:56:57 PDT
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
Comment 2 User image José Jeria 2003-09-11 10:44:17 PDT
Also see this. The sites dont use frames though, changing summary. 
Comment 3 User image ktml 2003-09-16 17:16:39 PDT
This webpage has table rendering problem as well, it can be reproduced every time.
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?
Comment 4 User image Darryl C. 2003-09-16 17:52:36 PDT
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 5 User image ktml 2003-09-18 09:49:18 PDT
Created attachment 131681 [details]
Comment 6 User image ktml 2003-09-18 09:59:01 PDT
Comment on attachment 131681 [details]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030918
Comment 7 User image Hussam Al-Tayeb 2003-09-24 10:35:58 PDT
this could be a dublicate of
Comment 8 User image ktml 2003-09-25 03:08:22 PDT
More testcases - 75% chance of bad rendering - 100% chance(so far) of bad rendering, have to scroll
right to see the menu bar
Comment 9 User image José Jeria 2003-09-25 04:04:47 PDT
--> changing component and reassigning
Comment 10 User image Hussam Al-Tayeb 2003-09-27 02:04:16 PDT
this could be a dublicate of 215857
Comment 11 User image Bernd 2003-09-27 02:45:59 PDT
>More testcases
> - 75% chance of bad rendering
> - 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 . 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.

Comment 12 User image Hussam Al-Tayeb 2003-09-27 03:00:53 PDT
re Comment #11 , but still this is an isse and should be addressed. It is rather
easy to reproduce especially with slow conmnections
Comment 13 User image Bernd 2003-09-27 13:30:25 PDT
>re Comment #11 , but still this is an isse and should be addressed.

are you volunteering to fix this?
Comment 14 User image Hussam Al-Tayeb 2003-09-27 15:03:10 PDT
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.
Comment 15 User image Bernd 2003-09-27 23:27:00 PDT
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 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 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.
Comment 16 User image James Chaldecott 2003-10-23 03:02:06 PDT
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. - maybe
they're just under too much load).

As a further bit of info, I find that I see this problem on 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)

Comment 17 User image Aditya N 2003-10-23 03:52:58 PDT
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.
Comment 18 User image Kirys 2003-10-23 04:14:38 PDT
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).
Comment 19 User image Jason Barnabe (np) 2003-10-23 21:10:21 PDT
*** Bug 221194 has been marked as a duplicate of this bug. ***
Comment 20 User image Jason Barnabe (np) 2003-10-23 22:51:01 PDT
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?
Comment 21 User image Hussam Al-Tayeb 2003-10-24 08:18:46 PDT
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
why it renders it correctly from cache as in bug 215857 which I think is a
dublicate of this one
Comment 22 User image Bob Firth 2003-10-25 21:49:17 PDT
*** Bug 220615 has been marked as a duplicate of this bug. ***
Comment 23 User image Mats Palmgren (:mats) 2003-11-13 13:10:55 PST
*** Bug 225588 has been marked as a duplicate of this bug. ***
Comment 24 User image José Jeria 2003-11-26 04:34:44 PST
*** Bug 226824 has been marked as a duplicate of this bug. ***
Comment 25 User image Jason Barnabe (np) 2003-11-27 20:56:26 PST
Created attachment 136440 [details]

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.
Comment 26 User image Jason Barnabe (np) 2003-11-27 21:04:30 PST
Created attachment 136441 [details]

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.
Comment 27 User image Mats Palmgren (:mats) 2003-12-12 18:37:42 PST
FYI, this bug still occurs in 2003-12-12-09 (after bug 215857 was fixed)
Both at
Comment 28 User image Hussam Al-Tayeb 2003-12-13 04:06:16 PST
Preblem still exists here on too. using firebird 20031211
Comment 29 User image David Baron :dbaron: ⌚️UTC-8 2003-12-17 09:26:49 PST
*** Bug 228742 has been marked as a duplicate of this bug. ***
Comment 30 User image Manoj 2003-12-18 23:23:04 PST
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.
Comment 31 User image Asa Dotzler [:asa] 2003-12-19 10:24:15 PST
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
Comment 32 User image David Baron :dbaron: ⌚️UTC-8 2003-12-19 11:01:11 PST
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.
Comment 33 User image Jason Barnabe (np) 2003-12-19 12:38:01 PST
Created attachment 137719 [details]
testcase image
Comment 34 User image Jason Barnabe (np) 2003-12-19 12:41:33 PST
Created attachment 137720 [details]

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.
Comment 35 User image David Baron :dbaron: ⌚️UTC-8 2003-12-31 08:54:19 PST
I still don't see the problem with this testcase.
Comment 36 User image Noel Llopis 2003-12-31 10:23:21 PST
In case it's of any help, here's another web site with a similar problem.

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.
Comment 37 User image Hussam Al-Tayeb 2003-12-31 10:48:11 PST
Re Comment #35
Try the following url too.
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)

Comment 38 User image chris hofmann 2004-01-06 12:19:24 PST
1.6- for now.,  renominate if a fix appears in the next few days.
Comment 39 User image MORA 2004-01-07 06:07:11 PST
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,, and
Sometimes the problem is visible after a couple of reloads only. No problems
with, 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. 
Comment 40 User image Michael Perrin 2004-01-07 12:40:21 PST
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 (see comment
39)). Here is an example with bigger images : . 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.
Comment 41 User image Hussam Al-Tayeb 2004-01-07 13:04:17 PST
One question. 
Open 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.
Comment 42 User image Hussam Al-Tayeb 2004-01-10 13:09:20 PST
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?
Comment 43 User image David Baron :dbaron: ⌚️UTC-8 2004-01-10 13:14:14 PST
The chance that this is going to be fixed without a testcase that developers can
use to see the bug is rather low.
Comment 44 User image José Jeria 2004-01-10 14:39:18 PST
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?
Comment 45 User image Adam Hauner 2004-01-11 00:14:41 PST
David: This bug is messing design of Lupa <> 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 
Comment 46 User image David Baron :dbaron: ⌚️UTC-8 2004-01-11 00:28:30 PST
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.
Comment 47 User image Patrick Quaedackers 2004-01-13 02:22:37 PST
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.
Comment 48 User image David Baron :dbaron: ⌚️UTC-8 2004-01-13 11:01:38 PST
No patch in sight, and we've shipped with this before, so we're not going to
hold 1.6 for it.
Comment 49 User image Hussam Al-Tayeb 2004-01-13 21:59:17 PST
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.
Comment 50 User image Jason Barnabe (np) 2004-01-19 15:59:51 PST
Created attachment 139452 [details]
new testcase

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.
Comment 51 User image Jason Barnabe (np) 2004-01-19 16:03:39 PST
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.
Comment 52 User image David Baron :dbaron: ⌚️UTC-8 2004-01-19 21:38:00 PST
Created attachment 139475 [details]
simplified testcase

Reproducable 100% of the time.
Comment 53 User image Aditya N 2004-01-19 23:58:35 PST
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
Comment 54 User image Eric Price 2004-01-21 07:09:56 PST
Created attachment 139572 [details]

This problem doesn't happen all the time. Sometimes the page will be fine but
half the time it looks like that.
Comment 55 User image Patrick Quaedackers 2004-01-22 05:19:22 PST
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!
Comment 56 User image David Baron :dbaron: ⌚️UTC-8 2004-01-23 16:04:41 PST
Created attachment 139763 [details]
Comment 57 User image David Baron :dbaron: ⌚️UTC-8 2004-01-23 16:56:03 PST
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
Comment 58 User image David Baron :dbaron: ⌚️UTC-8 2004-01-23 16:58:50 PST
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)
Comment 59 User image David Baron :dbaron: ⌚️UTC-8 2004-01-23 19:13:26 PST
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.
Comment 60 User image Andrew Schultz 2004-01-23 19:29:02 PST
only drivers can set (+) blocking flags.  you can request them (?)
Comment 61 User image Jason Barnabe (np) 2004-01-23 20:53:26 PST
It was set to blocking1.7a? by before it was set to
blocking1.7+ by, so I'll set it back to blocking1.7a?.
Comment 62 User image David Baron :dbaron: ⌚️UTC-8 2004-01-23 22:03:33 PST
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)...
Comment 63 User image Bernd 2004-01-23 23:07:44 PST
The max width problem looks very similiar to bug 39683, so this might be a very
old issue
Comment 64 User image David Baron :dbaron: ⌚️UTC-8 2004-01-23 23:12:53 PST
I have a fix.  I just want to clean it up a bit.
Comment 65 User image David Baron :dbaron: ⌚️UTC-8 2004-01-23 23:20:45 PST
Created attachment 139782 [details] [diff] [review]

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:
Comment 66 User image David Baron :dbaron: ⌚️UTC-8 2004-01-24 11:24:49 PST
Comment on attachment 139782 [details] [diff] [review]

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.
Comment 67 User image David Baron :dbaron: ⌚️UTC-8 2004-01-26 21:48:43 PST
Fix checked in to trunk, 2004-01-26 21:47 -0800.
Comment 68 User image David Baron :dbaron: ⌚️UTC-8 2004-01-26 22:22:53 PST
Created attachment 139960 [details] [diff] [review]
a little additional cleanup
Comment 69 User image Boris Zbarsky [:bz] (still a bit busy) 2004-01-26 22:45:16 PST
Comment on attachment 139960 [details] [diff] [review]
a little additional cleanup

Comment 70 User image Luke Montague 2004-01-28 14:18:19 PST
Bug still not fixed when viewing, 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)
Comment 71 User image ktml 2004-01-28 14:35:19 PST
my guess is the patch wasn't applied to stipe 20040127 build. I tried 
scragz 20040127 build, I can't see any problem with anymore! I have
been waiting for a long time for this bug to be solved, thanks David for solving
this annoying bug =)
Comment 72 User image Daniel Cachapa 2004-01-28 22:05:29 PST
> my guess is the patch wasn't applied to stipe 20040127 build. I tried 
> scragz 20040127 build, I can't see any problem with anymore!

Gamespot wfm now, but I just got the same problem with the slashdot comment pages.
Using scragz' build #20040128.
Can anyone confirm?
Comment 73 User image Julien Muchembled 2004-01-28 22:45:43 PST
Still problems with first loads : (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) :

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
Comment 74 User image Jason Barnabe (np) 2004-01-29 21:48:07 PST

See bug 232625 for problems . If you
continue to have problems with sites other than gamespot, file a new bug.
Comment 75 User image Matthew Miller 2004-01-30 06:41:34 PST
I'm still seeing this with slashdot (as comment #72). Has someone opened a new
bug for that yet?
Comment 76 User image Patrick Quaedackers 2004-01-30 07:09:56 PST
(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?
Comment 77 User image David Baron :dbaron: ⌚️UTC-8 2004-01-30 10:20:48 PST
The problem on slashdot may be bug 217527.  (But did you read comment 46?)
Comment 78 User image Luke Montague 2004-01-30 10:57:51 PST
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.
Comment 79 User image Bernd 2004-02-03 22:42:05 PST
*** Bug 223363 has been marked as a duplicate of this bug. ***
Comment 80 User image Olivier Cahagne 2004-02-14 13:07:28 PST
*** Bug 234352 has been marked as a duplicate of this bug. ***
Comment 81 User image Mats Palmgren (:mats) 2004-02-25 13:38:44 PST
*** Bug 230690 has been marked as a duplicate of this bug. ***
Comment 82 User image Patrick 2004-03-08 10:52:09 PST
Created attachment 143307 [details]
Screenshot of with Moz 2004030409 on XP Pro

Not sure if this is the same issue, but with a recent nightly again displays too wide sometimes. Anyone?
Comment 83 User image José Jeria 2004-03-08 13:15:27 PST
(In reply to comment #82)
> Not sure if this is the same issue, but with a recent nightly again
> 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.
Comment 84 User image Hussam Al-Tayeb 2004-03-09 02:13:46 PST
New bug filed yet?
Comment 85 User image Tim Meader 2004-03-11 13:41:33 PST
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.
Comment 86 User image David Baron :dbaron: ⌚️UTC-8 2004-03-11 13:53:57 PST
This was fixed well after Firefox 0.8 branched.
Comment 87 User image Tim Meader 2004-03-11 14:05:21 PST
Apologies... after dbaron's notification, I downloaded and tried it with 
Mozilla 1.7a. does indeed to be working fine now.

Thanks, and sorry again.
Comment 88 User image Olivier Cahagne 2004-03-23 21:50:25 PST
*** Bug 238462 has been marked as a duplicate of this bug. ***
Comment 89 User image Patrick Quaedackers 2004-04-06 12:40:29 PDT
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)
Comment 90 User image Bernard Alleysson 2004-04-10 04:47:24 PDT
*** Bug 240145 has been marked as a duplicate of this bug. ***
Comment 91 User image Hussam Al-Tayeb 2004-04-10 05:43:23 PDT
(In reply to comment #89)
Can you please files an new bug about and meantion the
bug # here?

Comment 92 User image Patrick Quaedackers 2004-04-10 13:44:23 PDT
Ok... I've filed the bug for for Mozilla 1.7beta as bug 240175 .

Note You need to log in before you can comment on or make changes to this bug.