Closed Bug 217369 Opened 21 years ago Closed 21 years ago

{inc}gamespot.com pages sometimes too wide/messed up on first load

Categories

(Core :: Layout: Tables, defect, P1)

Product:
Core
Component:
Layout: Tables
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.7alpha

People

(Reporter: nawal_adi, Assigned: dbaron)

References

(
URL
)

Details

(Keywords: testcase, Whiteboard: [patch])

Attachments

(6 files, 6 obsolete files)

screenshot
269.92 KB, image/jpeg
Details
screenshot
172.69 KB, image/jpeg
Details
testcase
429 bytes, text/html; charset=UTF-8
Details
patch
2.89 KB, patch
roc
: review+
roc
: superreview+
Details | Diff | Splinter Review
a little additional cleanup
3.89 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
Screenshot of Gamespot.com with Moz 2004030409 on XP Pro
268.27 KB, image/jpeg
Details 
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.
Summary: frames do not display, or are too wide → Page sometimes too wide/messed up. A reload cures problem.
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.
Whiteboard: URL in comment 3 is 100% reproducibable
Attached image screenshot — 

    
    

    
  
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+

    
    

    
  
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
Assignee: general → table
Component: Browser-General → Layout: Tables
QA Contact: general → madhur
Summary: Page sometimes too wide/messed up. A reload cures problem. → {inc}Page sometimes too wide/messed up. A reload cures problem.

    
    

    
  
this could be a dublicate of 215857
Depends on: 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?
Whiteboard: URL in comment 3 is 100% reproducibable

    
    

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

    
  
Blocks: 200047

    
    

    
  
*** Bug 225588 has been marked as a duplicate of this bug. ***
Depends on: 217590

    
    

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

    
    

    
  

      
      
      
      

        Attached file
          
        testcase (obsolete)
        — 
      

    


  
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.

    
    

    
  

      
      
      
      

        Attached file
          
        testcase (obsolete)
        — 
      

    


  
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.

    
  

        Attachment #136440 -
        Attachment is obsolete: true

    
    

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

    
    

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

    
    

    
  

      
      
      
      

        Attached image
          
        testcase image (obsolete)
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached file
          
        testcase (obsolete)
        — 
      

    


  
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.

    
  

        Attachment #136441 -
        Attachment is obsolete: true

    
    

    
  
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)


Flags: blocking1.7a?
Summary: {inc}Page sometimes too wide/messed up. A reload cures problem. → {inc}gamespot.com pages sometimes too wide/messed up on first load

    
    

    
  
1.6- for now.,  renominate if a fix appears in the next few days.
Flags: blocking1.6? → blocking1.6-

    
    

    
  
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.

    
  
Keywords: testcase

    
    

    
  
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?
Flags: blocking1.6- → blocking1.6?

    
    

    
  
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.
Flags: blocking1.6? → blocking1.6-

    
    

    
  
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.

    
    

    
  

      
      
      
      

        Attached file
          
        new testcase (obsolete)
        — 
      

    


  
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.

        Attachment #137719 -
        Attachment is obsolete: true

        Attachment #137720 -
        Attachment is obsolete: true

    
    

    
  
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.
OS: Windows XP → All
Hardware: PC → All

    
    

    
  

      
      
      
      

        Attached file
          
        simplified testcase (obsolete)
        — 
      

    


  
Reproducable 100% of the time.

        Attachment #139452 -
        Attachment is obsolete: true

    
    

    
  
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

    
    

    
  

      
      
      
      

        Attached image
          
        screenshot
        — 
      

    


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

        Attachment #131681 -
        Attachment description: Example of bad table rendering → screenshot

        Attachment #139572 -
        Attachment description: Part of the site goes to the right. → screenshot

    
    

    
  
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!

    
  
Flags: blocking1.7a? → blocking1.7a+

    
    

    
  

      
      
      
      

        Attached file
          
        testcase
        — 
      

    


  

        Attachment #139475 -
        Attachment is obsolete: true

    
    

    
  
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 (?)
Flags: blocking1.7a+

    
    

    
  
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?.
Flags: 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.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch
        — 
          — Splinter 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:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/base/src/nsBlockFrame.cpp&rev=3.602&mark=3171-3172#3166
Assignee: core.layout.tables → dbaron
Priority: -- → P1
Whiteboard: [patch]
Target Milestone: --- → mozilla1.7alpha

    
    

    
  
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.

        Attachment #139782 -
        Flags: superreview?(roc)

        Attachment #139782 -
        Flags: review?(roc)

        Attachment #139782 -
        Flags: superreview?(roc)

        Attachment #139782 -
        Flags: superreview+

        Attachment #139782 -
        Flags: review?(roc)

        Attachment #139782 -
        Flags: review+

    
    

    
  
Fix checked in to trunk, 2004-01-26 21:47 -0800.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED

    
    

    
  
Comment on attachment 139960 [details] [diff] [review]
a little additional cleanup

r+sr=bzbarsky

        Attachment #139960 -
        Flags: superreview+

        Attachment #139960 -
        Flags: review+

    
    

    
  
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.
Status: RESOLVED → VERIFIED

    
    

    
  
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.

    
  
Flags: blocking1.7a?

    
    

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

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: