Closed Bug 169620 Opened 22 years ago Closed 22 years ago

cnn.com news scrolls off the page; paragraphs do not wrap

Categories

(Core :: Layout, defect, P1)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.2beta

People

(Reporter: P, Assigned: karnaze)

References

(
URL
)

Details

(Keywords: regression, top100, topembed, Whiteboard: [adt2] [ETA Needed])

Attachments

(4 files)

Screenshot of cnn article.
82.71 KB, image/png
Details
testcase using the gettysburg address for long lines
1.74 KB, text/html
Details
patch to fix evil DEBUG-only code that hides this bug in DEBUG builds
1.47 KB, patch
bernd_mozilla
: review+
Details | Diff | Splinter Review
patch to fix the bug (including the evil debug code plus more)
8.16 KB, patch
dbaron
: review+
kinmoz
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020915
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020915

All Paragraphs in news stories on cnn.com no not wrap but scroll far off to the
right.

Reproducible: Always

Steps to Reproduce:
1. Load any cnn.com story.
2. Paragraphs do not wrap.

Actual Results:  
No paragraphs wrap, story scrolls far off to the right.

Expected Results:  
You should be able to read the story without scrolling to the right.

Looks proper in IE 5.5 and Opera 6.
Attached image Screenshot of cnn article. — 

    
    

    
  
Looks fine in Netscape 7 also.
Turning off CSS with a bookmarklet I have fixes it.

The only stylesheet on the page is:
http://www.cnn.com/.element/ssi/css/1.0/main.css
But I don't see anything in it that might be the cause.

The HTML is certainly not valid though.

    
    

    
  
Works for me on Gecko/20020823  commercial branch Win2K upon first time
accessing the page.

Can you still replicate? 
If so I will flip this to a browser bug.

    
    

    
  
WFM in Netscape 7.0RTM
WFM in Mozilla 1.2a, build 2002091014, both on Win2K

    
    

    
  
Confirming bug with 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20020919
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
Confirming the bug in Build 2002091014, WinNT 4.0 SP6

    
    

    
  
WFM on Win2K with Gecko/20020917 commercial branch

Confirming the bug in Win2K with 1.2 alpha Build 2002091014 mozilla trunk AFTER
reloading. Initially page laid out correctly.

Marking as a layout regression
Assignee: susiew → attinasi
Component: US General → Layout
Keywords: nsbeta1, 
          
            top100, 
          
            topembed
Priority: -- → P1
Product: Tech Evangelism → Browser
QA Contact: zach → petersen
Summary: cnn.com news stories scroll far off the page; paragraphs do not wrap → cnn.com news scrolls off the page; paragraphs do not wrap
Version: unspecified → other

    
  
Keywords: regression

    
    

    
  
Kevin, please assign. Thanks.

    
    

    
  


  
This is a bug in the renderer of some sort.  The test case is as simple as I
can get it but it is still fairly complex.
To demonstrate this bug you need:
* Fairly long lines
* A div nested inside a table that contains those lines.
* An <hr> tag inside the div
* A second cell on that table (table must be at least two cells wide)
* Padding on the right of the div
* A JavaScript in the table that references "document"
* A Second JavaScript in the table loaded from an external page (could be empty
on non-existent)

Remove any one of these elements and the text wraps properly.

    
    

    
  
Dupe of bug 169568?  Or the other way around?

    
    

    
  
No wrap in 2002091908 linux. This is actually more than just not wrapping. It's
much wider then it would be in just <nobr>'s. Most of the horizontal space is blank.

    
    

    
  
-> Karnaze
Assignee: attinasi → karnaze

    
    

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

    
    

    
  
I am seeing this problem, both on cnn.com and with the attached test case, on a
Windows 20020918 build.  

Changing the text zoom (and optionally changing it back to 100%) causes the page
to render correctly.  

    
    

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

    
    

    
  
bug 169568 has another good testcase.

    
    

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

    
    

    
  
In bug 169568 comment 13, Andrew mentions the fix for bug 154780 as a possible
culprit?

    
    

    
  
Edit page renders the cnn and testcase correctly, most of the time, but the
browser has this bug.
2002091608 MacOS9.x trunk.

    
    

    
  
I download yesterday's trunk tarball , build it on sparc, 
it works fine, both testcase and url.
if it is a reflow bug, it should be the same on different platforms, 
but now I am surprised.



    
    

    
  
The bug is not 100% reproducible in my case either.
I have been on the same connection and Mozilla has been up running since my last
post (comment #20), but the testcase and the cnn render correctly now.

    
    

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

    
    

    
  
I see this bug on CNN 100% of the time.  It appears to layout correctly, but
then gets munged and goes wide after a reflow.  The weird part for me is this
100% effective workaround:

I can workaround this problem by causing a reload while holding the shift key. 
The shift key must be held through the reflow for this to work.  If I initiate
the reload with shift, and then release the shift before the reflow, the reflow
breaks the layout as reported.

    
    

    
  
I'm seeing exactly the same as Stephen.
Shift+reload only works if you keep the shift key pressed until the final layout.
Bizarre !!!!!

2002091904 NT4

    
    

    
  
I checked it with

Mozilla 1.0.1
Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20020913

and everything looks ok.

    
    

    
  
I'm seeing the same as Stephen in comment 24 also.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910

This is kinda weird -- especially the "shift"-key thing.

Maybe the NS bar on the top needs a note saying "only read our stories after
hitting shift-reload if you're using Gecko?

Uhhhh ... maybe not.

    
    

    
  
The testcase from the other bug is almost identical to the one I supplied here.
 It doesn't have long lines of text, proving long lines are not required for the
bug.  It does use a "document.write(...);" which can be shortened to just
"document;" and still produce the bug.

I congratulate Andrew Schultz on creating that testcase.  It took me over an
hour to pare away CNN's html, include their external documents, then whittle the
css and javascript down.  I wish I had seen that he had done it before I went
ahead and did it.

    
    

    
  
Also, since this bug depends on javascript, another work around is disable
javascript.

    
    

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

    
    

    
  
Have this problem with WinXP.

One question, someone mentioned that turning off the CSS fix the problem.  I
don't see that feature in the Preference setting from Mozilla.  Can anyone tell
me where it can be found?

The shift-reload does not fix the problem in my case as someone claimed.

    
    

    
  
shift+reload doesn't work for me either on Linux 20020918.

I also don't get an extra reflow as described in comment #24. I get the borked
page on the first reflow.

    
    

    
  
My shift-reload and relfow observations were based on WinXP Pro.  I'm also
confident that other observations like this are all Win32 based.

    
    

    
  
Well, mine is WinXP Professional.  Still, it doesn't work with shift-reload and 
reflow.  Look like I'm going to have to start using IE for reading the cnn.com 
articles.  I'm going to vote for this bug.

    
    

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

    
    

    
  
I can't reproduce the problem on my current win2k debug build.

    
    

    
  
> I can't reproduce the problem on my current win2k debug build.

debug build worksforme on linux as well.  however, it does complain:

Block(div)(5)@0x884c794: Init: bad caller: width WAS 1073741624(0x3fffff38)
which appears relevant to this bug

    
    

    
  
I also see this behaviour with Mozilla 1.2a running on Windows XP Professional SP1.

I was able to work around with the shift-reload and holding the shift button
down.  Strange stuff.

    
    

    
  


  
This patch fixes some extremely evil DEBUG-only code that prevents this bug
from being visible in DEBUG builds.  DEBUG code should be testing things, but
it shouldn't be changing them, since that makes bugs unreproducable in DEBUG
builds.

    
    

    
  
My testing of nightly builds shows that this started between 2002-09-04-04 and
2002-09-12-09.  Other comments in this bug show it was before 2002-09-10-14. 
Does anyone still have nightly builds from that period to reduce it further?

    
    

    
  
from bug 169568 comment 5
> trunk build 2002090905 works, trunk build 2002091016 (1.2a) does not

bug 154780 fits in that window and is consistent with the behavior here

    
    

    
  
Confirmed.  Backing out bug 154780 in my tree using the commands:

cvs up -j3.100 -j3.99 nsTableRowFrame.h
cvs up -j3.314 -j3.313 nsTableRowFrame.cpp

fixes this bug.

    
    

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

    
    

    
  
Comment on attachment 100100 [details] [diff] [review]
patch to fix evil DEBUG-only code that hides this bug in DEBUG builds

r=bernd

        Attachment #100100 -
        Flags: review+

    
  
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2beta

    
    

    
  


  
I think the patch in bug 154780 only exposed problems in the block/inline code
(e.g. supplying negative values for available widths and performing arithmetic
on unconstrained values). This patch also contains what's in the previous patch
plus another case of the same.

    
    

    
  
Comment on attachment 100129 [details] [diff] [review]
patch to fix the bug (including the evil debug code plus more)



So what exactly is being passed into the block code that's unconstrained that
never was before?


>Index: html/base/src/nsBlockReflowState.cpp
>-      mContentArea.width = aReflowState.availableWidth - lr;
>+      mContentArea.width = PR_MAX(0, aReflowState.availableWidth - lr);

>-    mContentArea.height = mBottomEdge - borderPadding.top;
>+    mContentArea.height = PR_MAX(0, mBottomEdge - borderPadding.top);

Does something bad happen if these go below zero?  (It makes sense, although
I'm wondering if there are obscure cases that it could break.)

>Index: html/base/src/nsHRFrame.cpp
>         // When the HR is using an 'auto' or percentage width, make sure it
>         // remains springy.
>         aDesiredSize.maxElementSize->width = onePixel;
>+        aDesiredSize.width = PR_MAX(aDesiredSize.width, onePixel);

>       aDesiredSize.maxElementSize->width = onePixel;
>+      aDesiredSize.width = PR_MAX(aDesiredSize.width, onePixel);

Perhaps we should instead have a better way of saying that the
maxElementSize->width is zero, instead of changing the width?  Can we just say
it's zero?  Or unconstrained?

>Index: html/base/src/nsInlineFrame.cpp
>     availableWidth -= aReflowState.mComputedBorderPadding.right;
>+    availableWidth = PR_MAX(0, availableWidth);

See comment above on nsBlockReflowState.cpp.

>Index: html/base/src/nsLineLayout.cpp
>   // Advance to next X coordinate
>   psd->mX = pfd->mBounds.XMost() + pfd->mMargin.right;
>+  psd->mRightEdge = PR_MAX(psd->mRightEdge, psd->mX);

Same comment as on BlockReflowState.cpp (except that it's not "below zero").

    
    

    
  
>So what exactly is being passed into the block code that's unconstrained 
>that never was before?

As far as I can tell, nothing. The block appears to be given an avail 
width of 0 and then reflowing frames internally with an unconstrained 
width, which causes some arithmetic on NS_UNCONSTRAINEDSIZE when 
constructing the reflow state. See the dump below.

>Does something bad happen if these go below zero?  (It makes sense, although
>I'm wondering if there are obscure cases that it could break.)

I'm not sure what the advantages are for allowing negative avail widths. When
I removed the code which ensures they are >= 0, I hit assertions where things
wanted to have negative desired widths (does that also make sense?), but it 
didn't cause any problems on the test case.

Should I develop another patch with this stuff removed and see if it breaks
any regression tests or is there some reason to allow negative avail widths?
I'm afraid that by allowing things to return negative desired widths we will
run into problems even if the regression tests don't catch it. If we allow
negative avail widths but not negative desired widths, then that could be a
big job involving a lot of frame classes.

>Perhaps we should instead have a better way of saying that the
>maxElementSize->width is zero, instead of changing the width? 
>Can we just say it's zero?  Or unconstrained?

I'm not sure, but I'll open another bug on this. It looks like
someone ran into problems when the HR's MES was set to 0. If it 
needs to be set > 0, then it makes sense to set the desired width
to match, otherwise it might cause problems for callers (I think
the table code is working around this problem). I'm not sure what 
would be gained by making it unconstrained. 

-----------

      tbl 037B1170 r=0 a=13350,UC c=UC,UC cnt=1932
       rowG 037B1328 r=0 a=UC,UC c=UC,UC cnt=1933
        row 037B14B4 r=0 a=UC,UC c=UC,UC cnt=1934
         cell 037B1628 r=0 a=UC,UC c=UC,UC cnt=1935
          block 037B1688 r=0 a=UC,UC c=UC,UC cnt=1936
           text 037BB05C r=0 a=UC,UC c=UC,UC cnt=1937
           text 037BB05C d=0,0 me=0
          block 037B1688 d=0,0 me=0
		  ....

	  tbl 037B1170 r=1 a=13350,UC c=UC,UC cnt=1975
       rowG 037B1328 r=1 a=90,UC c=90,UC cnt=1976
        row 037B14B4 r=1 a=90,UC c=90,UC cnt=1977
         cell 036C2380 r=0 a=UC,UC c=UC,UC cnt=1978
          block 036C23E0 r=0 a=UC,UC c=UC,UC cnt=1979
           text 036C2430 r=0 a=UC,UC c=UC,UC cnt=1980
           text 036C2430 d=0,0 me=0
          block 036C23E0 d=0,0 me=0
         cell 036C2380 d=30,60 me=30
         cell 037B1628 r=1 a=30,UC c=UC,UC cnt=1981
          block 037B1688 r=1 a=0,UC c=UC,UC cnt=1982 
           text 037BB05C r=2 a=UC,UC c=UC,UC cnt=1983
           text 037BB05C d=0,0 me=0
           text 037BB828 r=2 a=UC,UC c=UC,UC cnt=1984
           text 037BB828 d=0,0 me=0
           text 037BB8AC r=0 a=UC,UC c=UC,UC cnt=1985
           text 037BB8AC d=0,0 me=0
           text 037BB05C r=2 a=0,UC c=UC,UC cnt=1986
           text 037BB05C d=0,0
           text 037BB828 r=2 a=0,UC c=UC,UC cnt=1987
           text 037BB828 d=0,0
           text 037BB8AC r=2 a=0,UC c=UC,UC cnt=1988
           text 037BB8AC d=0,0
           block 037BBA00 r=0 a=UC,UC c=UC,UC cnt=1989
            text 037BBA84 r=0 a=UC,UC c=UC,UC cnt=1990
            text 037BBA84 d=0,0 me=0
            text 037BBA84 r=2 a=UC,UC c=UC,UC cnt=1991
            text 037BBA84 d=0,0
            block 037BBBE8 r=0 a=UC,UC c=UC,UC cnt=1992
             text 037BBAF4 r=0 a=UC,UC c=UC,UC cnt=1993
             text 037BBAF4 d=15780,285 me=1020
             text 037BBAF4 r=2 a=UC,UC c=UC,UC cnt=1994
             text 037BBAF4 d=15780,285
            block 037BBBE8 d=15780,300 me=1020 m=15780
            block 037BBBE8 r=2 a=UC,UC c=UC,UC cnt=1995
             text 037BBAF4 r=2 a=UC,UC c=UC,UC cnt=1996
             text 037BBAF4 d=15780,285 me=1020
             text 037BBAF4 r=2 a=UC,UC c=UC,UC cnt=1997
             text 037BBAF4 d=15780,285
            block 037BBBE8 d=15780,300 me=1020 m=15780
            text 037BBC98 r=0 a=UC,UC c=UC,UC cnt=1998
            text 037BBC98 d=0,0 me=0
            text 037BBC98 r=2 a=UC,UC c=UC,UC cnt=1999
            text 037BBC98 d=0,0
            block 037BBCDC r=0 a=UC,UC c=UC,UC cnt=2000
             text 037BBD2C r=0 a=UC,UC c=UC,UC cnt=2001
             text 037BBD2C d=16380,285 me=945
             text 037BBD2C r=2 a=UC,UC c=UC,UC cnt=2002
             text 037BBD2C d=16380,285
            block 037BBCDC d=16380,300 me=945 m=16380
            block 037BBCDC r=2 a=UC,UC c=UC,UC cnt=2003
             text 037BBD2C r=2 a=UC,UC c=UC,UC cnt=2004
             text 037BBD2C d=16380,285 me=945
             text 037BBD2C r=2 a=UC,UC c=UC,UC cnt=2005
             text 037BBD2C d=16380,285
            block 037BBCDC d=16380,300 me=945 m=16380
            text 037BBD9C r=0 a=UC,UC c=UC,UC cnt=2006
            text 037BBD9C d=0,0 me=0
            text 037BBD9C r=2 a=UC,UC c=UC,UC cnt=2007
            text 037BBD9C d=0,0
            block 037BBDE0 r=0 a=UC,UC c=UC,UC cnt=2008
             text 037BBE30 r=0 a=UC,UC c=UC,UC cnt=2009
             text 037BBE30 d=16890,285 me=885
             text 037BBE30 r=2 a=UC,UC c=UC,UC cnt=2010
             text 037BBE30 d=16890,285
            block 037BBDE0 d=16890,300 me=885 m=16890
            block 037BBDE0 r=2 a=UC,UC c=UC,UC cnt=2011
             text 037BBE30 r=2 a=UC,UC c=UC,UC cnt=2012
             text 037BBE30 d=16890,285 me=885
             text 037BBE30 r=2 a=UC,UC c=UC,UC cnt=2013
             text 037BBE30 d=16890,285
            block 037BBDE0 d=16890,300 me=885 m=16890
            text 037BBEA0 r=0 a=UC,UC c=UC,UC cnt=2014
            text 037BBEA0 d=0,0 me=0
            text 037BBEA0 r=2 a=UC,UC c=UC,UC cnt=2015
            text 037BBEA0 d=0,0
            block 037BBEE4 r=0 a=UC,UC c=UC,UC cnt=2016
             text 037BBF34 r=0 a=UC,UC c=UC,UC cnt=2017
             text 037BBF34 d=29310,285 me=1095
             text 037BBF34 r=2 a=UC,UC c=UC,UC cnt=2018
             text 037BBF34 d=29310,285
            block 037BBEE4 d=29310,300 me=1095 m=29310
            block 037BBEE4 r=2 a=UC,UC c=UC,UC cnt=2019
             text 037BBF34 r=2 a=UC,UC c=UC,UC cnt=2020
             text 037BBF34 d=29310,285 me=1095
             text 037BBF34 r=2 a=UC,UC c=UC,UC cnt=2021
             text 037BBF34 d=29310,285
            block 037BBEE4 d=29310,300 me=1095 m=29310
            text 037BBFA4 r=0 a=UC,UC c=UC,UC cnt=2022
            text 037BBFA4 d=0,0 me=0
            text 037BBFA4 r=2 a=UC,UC c=UC,UC cnt=2023
            text 037BBFA4 d=0,0
            block 036C1AC8 r=0 a=UC,UC c=UC,UC cnt=2024
             text 036C1B18 r=0 a=UC,UC c=UC,UC cnt=2025
             text 036C1B18 d=52140,285 me=1050
             text 036C1B18 r=2 a=UC,UC c=UC,UC cnt=2026
             text 036C1B18 d=52140,285
            block 036C1AC8 d=52140,300 me=1050 m=52140
            block 036C1AC8 r=2 a=UC,UC c=UC,UC cnt=2027
             text 036C1B18 r=2 a=UC,UC c=UC,UC cnt=2028
             text 036C1B18 d=52140,285 me=1050
             text 036C1B18 r=2 a=UC,UC c=UC,UC cnt=2029
             text 036C1B18 d=52140,285
            block 036C1AC8 d=52140,300 me=1050 m=52140
            text 036C1B88 r=0 a=UC,UC c=UC,UC cnt=2030
            text 036C1B88 d=0,0 me=0
            inline 036C1E40 r=0 a=UC,UC c=UC,UC cnt=2031
             inline 036C1EAC r=0 a=UC,UC c=UC,UC cnt=2032
              text 036C1F18 r=0 a=UC,UC c=UC,UC cnt=2033
              text 036C1F18 d=0,285 me=0
             inline 036C1EAC d=0,285 me=0
            inline 036C1E40 d=0,285 me=0 status=17153
            text 036C1B88 r=2 a=UC,UC c=UC,UC cnt=2034
            text 036C1B88 d=0,0
            inline 036C1E40 r=2 a=UC,UC c=UC,UC nif=036C2704 cnt=2035
             inline 036C1EAC r=2 a=UC,UC c=UC,UC cnt=2036
              text 036C1F18 r=2 a=UC,UC c=UC,UC cnt=2037
              text 036C1F18 d=0,285
             inline 036C1EAC d=0,285
            inline 036C1E40 d=0,0 status=17153
            inline 036C2704 r=0 a=UC,UC c=UC,UC pif=036C1E40 cnt=2038
             hr 036C1D00 r=0 a=UC,UC c=UC,UC cnt=2039
             hr 036C1D00 d=15,315 me=15
             inline 036C200C r=0 a=UC,UC c=UC,UC cnt=2040
              text 036C2078 r=0 a=UC,UC c=UC,UC cnt=2041
              text 036C2078 d=0,285 me=0
             inline 036C200C d=0,285 me=0
            inline 036C2704 d=15,285 me=15
            text 036C20BC r=0 a=UC,UC c=UC,UC cnt=2042
            text 036C20BC d=0,0 me=0
            text 036C20BC r=2 a=UC,UC c=UC,UC cnt=2043
            text 036C20BC d=0,0
           block 037BBA00 d=52290,3015 me=1245 m=52290
           block 037BBA00 r=2 a=0,UC c=UC,UC cnt=2044
            text 037BBA84 r=2 a=UC,UC c=UC,UC cnt=2045
            text 037BBA84 d=0,0 me=0
Block(div)(5)@037BBA00: Init: bad caller: width WAS 1073741674(0x3fffff6a)
            text 037BBA84 r=2 a=1073741674,UC c=UC,UC cnt=2046
            text 037BBA84 d=0,0
            block 037BBBE8 r=2 a=1073741674,UC c=UC,UC cnt=2047

    
    

    
  
>>   psd->mX = pfd->mBounds.XMost() + pfd->mMargin.right;
>>+  psd->mRightEdge = PR_MAX(psd->mRightEdge, psd->mX);

>Same comment as on BlockReflowState.cpp (except that it's not "below zero").

In this case, I seem to recall that someone does (psd->mRightEdge - psd->mX)
to get a negative avail width, so the previous comments of negative avail widths
apply. 



    
    

    
  
Comment on attachment 100129 [details] [diff] [review]
patch to fix the bug (including the evil debug code plus more)

I'd be willing (although not enthusiastic) to mark r=dbaron for the trunk. 
However, I'm not convinced that this is safe for the branch.  Without
understanding why this started happening, I don't see how we can tell that all
the regressions are fixed.

    
    

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

    
    

    
  
I think the following piece from the patch in bug 154780 explains why this
started happening. Before bug 154780, the cell probably reflowed its block with
an availWidth = 0 and a computedWidth = 0 (since it had balanced and the col
width == 0). After bug 154780 it reflowed with an availWidth = 0 and a
computedWidth = unconstrained. That combination caused problems.

+    // If the table will intialize the strategy (and balance) or balance, make
the computed 
+    // width unconstrained. This avoids having the cell block compute a bogus
max width 
+    // which will bias the balancing. Leave the avail width alone, since it is
a best guess.
+    // After the table balances, the cell will get reflowed with the correct
computed width.


    
    

    
  
While this is getting fixed, I've just found a somewhat bizarre workaround for
Linux, which works on 2002092010trunk

Just open the link in a new window (a new tab, in my case. I haven't tested new
window), using the middle mouse button and wait for it to finish loading.  Now,
close the new tab and reopen, using middle mouse click again. The second time,
the page should load correctly.
This does not appear to work using left click-back button-left click.

    
    

    
  
So does this fix (and the proposed reason it appeared) take into account why on 
a reload with shift, changing the text size, or a new tab makes it appear ok? 

Just curious.



    
    

    
  
The bug probably does not appear in situations described in the previous comment
because the reflow command sequence is different. Based on the dump in comment
#47, it takes a situation where a cell gets reflowed and has no width, then gets
an incremental reflow and gets a lot of width. It may also require that the
coalesced reflow command contains a dirty reflow targeted at the row which
causes a new cell to be reflowed for the 1st time (as the dump indicates).

    
    

    
  
This is a visible regresison that is effecting a topsite, so nsbeta1+.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2] [ETA Needed]

    
    

    
  
This is info of minimal use; I just went to a lot of trouble extracting the
troublesome parts of one of the bad cnn pages BEFORE I searched for this bug, so
I have to put my findings somewhere. This page causes the problem, but if /any/
of the lines marked XXX are removed, it lays out fine. The fourth patch ("patch
to fix the bug") does fix this page.

<html><body>
<table>
  <tr>
    <td>
      <div style="padding-right: 10px"> <!-- XXX -->
        <script>
          document.write('anything'); <!-- XXX -->
        </script>
        <script src="nosuchscript.js"></script> <!-- XXX -->
        <hr style="width: 464px;"> <!-- XXX -->
      </div>
    </td>
    <td width="160"></td> <!-- XXX -->
  </tr>
</table>
</body></html>

    
    

    
  
A third person has deconstructed cnn html,js,css hell! (congratulations, danm  ;-)

In danm's example:
You can change "document.write('anything');" to "document;"
You can remove the widths from the hr and td.

    
  
QA Contact: petersen → amar

    
    

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

    
    

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

    
    

    
  
Comment on attachment 100129 [details] [diff] [review]
patch to fix the bug (including the evil debug code plus more)

r=dbaron

        Attachment #100129 -
        Flags: review+

    
    

    
  
Comment on attachment 100129 [details] [diff] [review]
patch to fix the bug (including the evil debug code plus more)

sr=kin@netscape.com


==== To be consistent with the rest of layout should we use
NS_UNCONSTRAINEDSIZE instead of NS_MAXSIZE?

+  aRect.width = PR_MAX(mTopRightX, mBottomRightX);
+  if (NS_MAXSIZE != aRect.width) {
+    aRect.width -= aRect.x;
+  }
+  aRect.height = (NS_MAXSIZE == mBottomY) ? NS_MAXSIZE : mBottomY - mTopY;

        Attachment #100129 -
        Flags: superreview+

    
    

    
  
NS_UNCONSTRAINEDSIZE is defined in layout/html/base/src/nsHTMLReflowState.h and
isn't included by layout/base/src/nsSpaceManager.h

    
    

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

    
    

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

    
    

    
  
The patch is in the trunk. It is not needed in the branch, because bug 154780
wasn't checked into the branch.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
removing my name since it is fixed.  Receiving too many emails

    
    

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

    
    

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

    
    

    
  
Removing my name... sorry for the duplicate.

    
    

    
  
unsubscribe

    
    

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

    
    

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

    
    

    
  
v linux and windows.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
Verified.
Status: RESOLVED → VERIFIED

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
It is still occurring, still after patch.

    
    

    
  
it is still occurring, after new patch.

    
    

    
  
It is still occurring, after new patch.

    
    

    
  
Bug is still occurring, after patch.


    
    

    
  
I'm not seeing a problem with the previous url on a 10/10/2 debug build. If
there is a problem with an optimized build, please file a new bug, since this is
a different url.

    
    

    
  
Renee, what build of Mozilla are you using?  I just tried the link you gave with
build 2002101108, Win98, and it works for me.

    
    

    
  
Still not fixed, as of today 10/12/02/

    
    

    
  
Still not fixed, as of 10/12/02.

    
    

    
  
Still not fixed, as of 10/12/02.

    
    

    
  
Still not fixed, as of 10/12/02.

    
    

    
  
Still not fixed, as of 10/12/02.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
Renee, can you please post your build ID?  You can find the build ID in Mozilla
by choosing the Help->About Mozilla menu.  You should see text that looks
something like "Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20021011".
 The last part "rv:1.2b) Gecko/20021011" is what you need to report.  There is
no way for the rest of us to guess what version you are running.

    
    

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

    
    

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

    
    

    
  
I am in build Mozilla build 1.2A, and it is still happening in that build.

    
    

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

    
    

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

    
    

    
  
Posting Renee's build info that I received in email: Mozilla/5.0 (Windows; U;
Win 9x 4.90; en-US; rv:1.2a) Gecko/20020910

Renee, you really need to get a newer version of Mozilla.  This problem was
fixed near the end of September.

    
    

    
  
74 duplicates and counting! Party in my cube when it hits 100.

    
    

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

    
    

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

    
    

    
  
Regarding Warner's comment to Renee: It appears that Renee is using the most
recently posted binary build for Windows, released September 11.  Given the
large audience for these builds, and the potential help (as opposed to
hindrance) that this audience (myself included) may provide to Mozilla QA
efforts, may I suggest more frequent updates of the binaries?

    
    

    
  
http://www.cnn.com/2002/US/South/10/15/sniper.shootings/index.html
Build:  Mozilla 1.2a

Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2a) Gecko/20020910

If there is a later version, I am unaware that it exists.....and as you can see,
it is still occurring.

    
    

    
  
Renee, maybe I don't understand what you're saying, but how exactly could your
browser get fixed without you downloading a new version?

1.2a was broken originally, and the nightly builds (and eventually 1.2b) are
fixed. Why do you expect your browser to repair itself?

    
    

    
  
Renee, the binary releases are released only periodically.  The reason that this
is marked as 'FIXED', is because it has been fixed in the nightly builds.  So,
to see the fix, you can either download a nightly, or wait for 1.2beta, which
will probably be out soon.

If you'd like to always have the latest build, follow the 'Building Mozilla on
Microsoft Windows 32-bit Platforms' here:
http://www.mozilla.org/build/win32.html

    
    

    
  
"1.2a was broken originally, and the nightly builds (and eventually 1.2b) are
fixed. Why do you expect your browser to repair itself?"

That's not such a useful thing to say.  When you go to mozilla.org and click on
the "download" link in the sidebar, 1.2a is the only obvious version.  Saying
"go to the QA menu in Mozilla and look for the latest build" is more helpful.

    
    

    
  
I wasn't so much recommending a nightly build (I've gotten in trouble more than
once d/ling one, only to find more bugs than were fixed). I just didn't
understand the seemingly irritated tone the comments seemed to have. Renee
emailed me, and he does now have a nightly, so problem solved.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
I tried to download nightly build (mozilla-win32-talkback.zip) on 15/10/2002 to
verify that this bug is fixed.

What should I do about the files? Just replace the current installation? Or I
have to build them again?

I replaced the 1.2a installation, and starting mozilla only show the splash
screen. That's it. Is that normal? (for nightly build, I mean).

    
    

    
  
What platform are you on?  On Mac OS X and Windows 2000, I just downloaded the
new binary/installer/thing.  No recompilation.



    
    

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

    
    

    
  
Finally got rid of this bug by downloading 1.2 Beta. Thanks team!

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
  
Alias: CNN

    
  
Blocks: 199819

    
  
No longer blocks: 199819

    
  
Blocks: 66522

    
  
No longer blocks: 66522

    
  
Blocks: 234019

    
  
No longer blocks: 234019

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: