Closed Bug 217527 (slashdot) Opened 21 years ago Closed 20 years ago

{inc}left column on slashdot is sometimes too narrow or too wide for its contents

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.8alpha2

People

(Reporter: raccettura, Assigned: dbaron)

References

(
URL
)

Details

(Keywords: testcase, Whiteboard: See comments 95 and 108. Fixed on trunk, but not on aviary or 1.7 branch.)

Attachments

(11 files, 1 obsolete file)

Screenshot of problem
212.60 KB, image/png
Details
Save Page As ... of a Slashot comments page that displayed with no text when loaded from Slashdot
40.54 KB, application/octet-stream
Details
mostly simplified testcase
807 bytes, text/html; charset=UTF-8
Details
simpler still
537 bytes, text/html; charset=UTF-8
Details
reflow log
9.10 KB, text/plain
Details
reflow log for attachment 137272
8.43 KB, text/plain
Details
hack
1.24 KB, patch
dbaron
: review-
dbaron
: superreview-
Details | Diff | Splinter Review
patch
2.31 KB, patch
roc
: review+
roc
: superreview+
Details | Diff | Splinter Review
same idea
137.03 KB, image/pjpeg
Details
Is this the same bug? it doesn't look like the other posted problems
239.57 KB, image/png
Details
The "scrolled to the right" view of the above screenshot
154.81 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827

Attached screenshot displays this bug.  On occasion, some sites (most notably
slashdot) seem to be displaying this bug.

Noticed this a few days prior, but assumed it was some regression and was
tracked.  Now that 1.5 is beta.  It's time to report.

Reproducible: Sometimes

Steps to Reproduce:
1.  Slashdot
2.  Reload
3.  Look
4.  File comment for this bug
Attached image Screenshot of problem — 

    
    

    
  
WFM windows 2003 mozilla 1.5b
Summary: Reloads can cause undesired  table oddities → {inc}Reloads can cause undesired  table oddities

    
    

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

    
    

    
  
I've seen this as well, on Linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: {inc}Reloads can cause undesired  table oddities → {inc}left column on slashdot is sometimes too narrow for its contents

    
    

    
  
(Sorry about the dupe--I swear, I searched for "/\." and "slashdot" more than
once each!)

    
    

    
  
I also can verify this behaviour, it only ever happens when reading slashdot. In
addition, sometimes the main table section in /. fails to render at all (I get
the links down the side, but nothing but blank space in the middle).

It only seems to happen occasionally though. If I've got a blank main page on /.
and then click on, for example, the "Apache" section, then that loads perfectly.
Going back to the main page, I get a blank middle section.

If I do get the main page, then I get the overlap bug that's reported here.

I only ever see this behaviour on /., never on any other websites.

I'm using Moz 1.5RC2 on a fully patched Win2k machine.

I'm also using Moz 1.5RC2 at work on one of their Win2k machines, and I *don't*
see the bug there. I'm not sure what that means. :/

    
    

    
  
Everything the guy above said, except I'm on WinXP

    
    

    
  
I see misbehavior in Slashdot's layout as well (far too wide more often than
too narrow), but if I save a page as "Web Page, complete" and load it from my
local machine, the page that misbehaved when loaded from slashdot.org seems
*not* to misbehave when loaded from file:.  Race condition perhaps?
Summary: {inc}left column on slashdot is sometimes too narrow for its contents → {inc}left column on slashdot is sometimes too narrow or too wide for its contents

    
    

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

    
    

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

    
    

    
  
I am seeing this exact same behavior on Mozilla and Firebird:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925

Platform: Linux

My experience with it matches what commnet #6 reports

    
    

    
  
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925

Happens here for Mozilla and Firebird.  Attached is a Save Page As ... zip. 
When the files are loaded from the save, the text is there, but the ad appears
twice.  It appears twice when the save file is loaded in Opera 7.21, and in IE
6.0.2800.1106.


    
    

    
  
I've seen this as well on slashdot.  It does not occur frequently for me, but
I've seen it a couple times in the last week or so (using firebird 0.7). 
Sometimes reloading the page fixes things, other times it persists over multiple
reloads. 

    
    

    
  
I'm seeing comment 6 a lot on slashdot.  Changing the paint delay to a large
value seems to make it not happen anymore.

    
    

    
  
There's a chance the patch to bug 215857 will fix this, although I suspect not.

    
    

    
  
Possibly related - each load of slashdot.org is throwing up a "free memory
read" error with purify in table layout:

[E] FMR: Free memory read in nsRect::IsEmpty(void)const {3 occurrences}
        Reading 4 bytes from 0x0c8b7d14 (4 bytes at 0x0c8b7d14 illegal)
        Address 0x0c8b7d14 is 12 bytes into a 16 byte block at 0x0c8b7d08
        Address 0x0c8b7d14 points to a C++ new block in heap 0x02390000
        Thread ID: 0x784
        Error location
            nsRect::IsEmpty(void)const [nsrect.h:66]
            nsRect::UnionRect(nsRect const&,nsRect const&) [nsrect.cpp:126]
            nsTableOuterFrame::InvalidateDamage(nsIPresContext *,BYTE,nsSize
const&,int,int,nsRect *) [nstableouterframe.cpp:634]
            nsTableOuterFrame::IR_InnerTableReflow(nsIPresContext
*,nsHTMLReflowMetrics&,nsHTMLReflowState const&,UINT&) [nstableouterframe.cpp:1766]
            nsTableOuterFrame::IR_TargetIsInnerTableFrame(nsIPresContext
*,nsHTMLReflowMetrics&,nsHTMLReflowState const&,UINT&) [nstableouterframe.cpp:1445]
            nsTableOuterFrame::IR_TargetIsChild(nsIPresContext
*,nsHTMLReflowMetrics&,nsHTMLReflowState const&,UINT&,nsIFrame *)
[nstableouterframe.cpp:1418]
            nsTableOuterFrame::IncrementalReflow(nsIPresContext
*,nsHTMLReflowMetrics&,nsHTMLReflowState const&,UINT&) [nstableouterframe.cpp:1398]
            nsTableOuterFrame::Reflow(nsIPresContext
*,nsHTMLReflowMetrics&,nsHTMLReflowState const&,UINT&) [nstableouterframe.cpp:1938]
            nsBlockReflowContext::ReflowBlock(nsRect
const&,int,nsCollapsingMargin&,int,nsMargin&,nsHTMLReflowState&,UINT&)
[nsblockreflowcontext.cpp:518]
           
nsBlockFrame::ReflowBlockFrame(nsBlockReflowState&,nsLineList_iterator,int *)
[nsblockframe.cpp:3094]
        Allocation location
            new(UINT)      [newop.cpp:10]
            nsFrame::GetOverflowAreaProperty(nsIPresContext *,int)
[nsframe.cpp:4285]
            nsFrame::StoreOverflow(nsIPresContext *,nsHTMLReflowMetrics&)
[nsframe.cpp:4306]
            nsTableOuterFrame::UpdateReflowMetrics(nsIPresContext
*,BYTE,nsHTMLReflowMetrics&,nsMargin const&,nsMargin const&,nsMargin
const&,nsMargin const&,nsMargin const&,int) [nstableouterframe.cpp:1373]
            nsTableOuterFrame::Reflow(nsIPresContext
*,nsHTMLReflowMetrics&,nsHTMLReflowState const&,UINT&) [nstableouterframe.cpp:2025]
            nsBlockReflowContext::ReflowBlock(nsRect
const&,int,nsCollapsingMargin&,int,nsMargin&,nsHTMLReflowState&,UINT&)
[nsblockreflowcontext.cpp:518]
           
nsBlockFrame::ReflowBlockFrame(nsBlockReflowState&,nsLineList_iterator,int *)
[nsblockframe.cpp:3094]
            nsBlockFrame::ReflowLine(nsBlockReflowState&,nsLineList_iterator,int
*,int) [nsblockframe.cpp:2324]
            nsBlockFrame::ReflowDirtyLines(nsBlockReflowState&)
[nsblockframe.cpp:2107]
            nsBlockFrame::Reflow(nsIPresContext
*,nsHTMLReflowMetrics&,nsHTMLReflowState const&,UINT&) [nsblockframe.cpp:815]
        Free location
            <>=(UINT)      [newaop.cpp:8]
            DestroyRectFunc [nsframe.cpp:4257]
            FrameManager::PropertyList::RemovePropertyForFrame(nsIPresContext
*,nsIFrame *) [nsframemanager.cpp:2503]
            FrameManager::RemoveFrameProperty(nsIFrame *,nsIAtom *)
[nsframemanager.cpp:2303]
            nsFrame::StoreOverflow(nsIPresContext *,nsHTMLReflowMetrics&)
[nsframe.cpp:4321]
            nsTableOuterFrame::UpdateReflowMetrics(nsIPresContext
*,BYTE,nsHTMLReflowMetrics&,nsMargin const&,nsMargin const&,nsMargin
const&,nsMargin const&,nsMargin const&,int) [nstableouterframe.cpp:1373]
            nsTableOuterFrame::IR_InnerTableReflow(nsIPresContext
*,nsHTMLReflowMetrics&,nsHTMLReflowState const&,UINT&) [nstableouterframe.cpp:1762]
            nsTableOuterFrame::IR_TargetIsInnerTableFrame(nsIPresContext
*,nsHTMLReflowMetrics&,nsHTMLReflowState const&,UINT&) [nstableouterframe.cpp:1445]
            nsTableOuterFrame::IR_TargetIsChild(nsIPresContext
*,nsHTMLReflowMetrics&,nsHTMLReflowState const&,UINT&,nsIFrame *)
[nstableouterframe.cpp:1418]
            nsTableOuterFrame::IncrementalReflow(nsIPresContext
*,nsHTMLReflowMetrics&,nsHTMLReflowState const&,UINT&) [nstableouterframe.cpp:1398]

    
    

    
  
Not related (unless the problem goes away on repaint, which I don't think it
does).  Please file a separate bug.

    
    

    
  
I filed bug 226870

    
    

    
  
Some extra information:
- Some pages of slashdot (like the user page) have this problem a lot more
  then the main page or the articles page.
- When reading comments it very often happens that the comments are simply
  not there. i.e. I get the see the entire slashdot frame with borders, ad,
  and so on but not the text of the comments.
- Pressing reload *may* (but not always) fix the problem.
- I have this problem on WinXP with 1.5 and on Linux with 1.4.
- I have one other site where a problem similar to this occurs from time
  to time: http://crystal.sf.net  The main page is always ok but sometimes
  the sub-pages appear to the right. i.e. there is a wide column of empty
  space that appears left of the actual contents. This only happens on linux
  and reload presses it. I'm not sure that this is actually the same bug or
  if this is a problem in tikiwiki. But it only appears on Linux with
  Mozilla.

Greetings,
  appears 

    
    

    
  
Well it appears the problem has gotten a LOT worse with 1.5 compared to 1.4.
Today I upgraded on WinXP from 1.4 to 1.5 and slashdot article pages are now
always blank for me. i.e. I can't read the comments on the following page for
example:

http://slashdot.org/comments.pl?sid=88723&threshold=-1&commentsort=3&tid=117&tid=129&tid=137&tid=188&tid=99&mode=thread&pid=7679130

    
  
Flags: blocking1.6?

    
    

    
  
dbaron will have a look

    
    

    
  

      
      
      
      

        Attached file
          
        slightly simpler testcase (obsolete)
        — 
      

    


  
This testcase is simpler than the previous one, but a little more different
from the structure showing the bug on slashdot, so I wanted to attach the
slightly more complex one as well.

    
    

    
  
I suspect this is roughly the same problem as bug 215857, but for floats being
part of max element width.

    
    

    
  

      
      
      
      

        Attached file
          
        simpler still
        — 
      

    


  
This is simpler still.

Actually, I'm thinking this is a table bug, since removing the second cell
within the floating table makes the problem go away.

    
    

    
  
For any of the three testcases I attached, remove the line:

<script type="text/javascript">var foo = document.body.offsetHeight;</script>

to see the correct layout.

    
    

    
  

      
      
      
      

        Attached file
          
        reflow log
        — 
      

    


  
cell 0271B1BC r=1 a=252,UC c=252,UC cnt=904 
	  block 0271B230 r=1 a=252,UC c=252,UC cnt=905 
	   text 02727560 r=2 a=UC,UC c=UC,UC cnt=906 
	   text 02727560 d=0,0 me=0 
	   place 02727F54 r=2 a=UC,UC c=UC,UC cnt=907 
	   place 02727F54 d=0,0 me=0 
	   tblO 0272777C r=1 a=UC,UC c=UC,UC cnt=908 
	    tbl 02727880 r=1 a=UC,UC c=UC,UC cnt=909 
	     rowG 02727984 r=1 a=252,UC c=252,UC cnt=910 

Tables have difficulties with unconstrained incr. reflows.
below follows the reference without a floating table, where the result of the
reflow is OK.

	 cell 02712E5C r=1 a=252,UC c=252,UC cnt=902 
	  block 02712ED0 r=1 a=252,UC c=252,UC cnt=903 
	   tblO 0271F10C r=1 a=252,UC c=0,UC cnt=904 
	    tbl 0271F210 r=1 a=252,UC c=UC,UC cnt=905 
	     rowG 0271F2D8 r=1 a=252,UC c=252,UC cnt=906

    
    

    
  
oops, I forgot to mention, that before the checkin for bug 172896 , the removal
of NS_BLOCK_WRAPSIZE, the outer table cell would have wrapped the overflowing
block and produced a "correct" rendering of the testcase.

    
    

    
  
The problem with unconstrained incr. reflows issued at tables in order to get
the MEW seems to me like a structural problem.
nsTableFrame::CalcMinAndPreferedWidths
(http://lxr.mozilla.org/seamonkey/search?string=%3A%3ACalcMinAndPreferredWidths
) relies on the knowledge of the MIN and MIN_ADJ widths for every colframe.
These widths are computed during the column balancing (
http://lxr.mozilla.org/seamonkey/search?string=%3A%3ABalanceColumnWidths ). As
http://lxr.mozilla.org/seamonkey/source/layout/html/table/src/BasicTableLayoutStrategy.cpp#234
indicates  NS_ASSERTION(NS_UNCONSTRAINEDSIZE != maxWidth, "cannot balance with
an unconstrained width"); this will not happen during an unconstrained incr.
reflow. Which is also clear as the distribution of the min width between the
columns for colspans depends on their size, especially the percent sizes, which
depend on the table size. I backed out already an simliar attempt to issue
unconstrained reflows on tables to determine the size ( bug 97777) because it
does not work. 
I don't see that there is an easy solution to this, waiting for dbarons layout
rewrite might be an option. My prefered solution would be however using a reflow
with the viewport width as a constrain, but I have to admit that I don't really
understand that float buisiness.

    
    

    
  
Comment on attachment 137359 [details]
reflow log

>           tblO 0272777C d=576,480 me=576 
>           text 0272AB74 r=2 a=0,480 c=UC,UC cnt=947 
>           text 0272AB74 d=0,0 
>          block 0271B230 d=252,480 me=251 m=252 o=(0,0) 576 x 480
>         cell 0271B1BC d=252,480 me=252 m=252 

Actually, this makes it look like a block bug.

    
    

    
  


  
This is the reflow log I see, which disagrees with attachment 137359 [details] and agrees
more with the other comments.

    
    

    
  
Comment on attachment 137272 [details]
simpler still

The behavior on this testcase regressed between mozilla1.0 and mozilla1.0.1.

    
    

    
  
...and between 1.0 and 1.1a.  That means it was something checked into the 1.0
branch between 5-29 and 6-11.  Most likely, the reflow tree landing.

    
    

    
  
I confirmed that the regression on the trunk was between 2002-05-09-21 and
2002-05-13-21.  The reflow tree patch is attachment 82984 [details] [diff] [review].

    
    

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

    
    

    
  
need to 1.6- for now.  lets get a patch for the trunk and renominate if
something low risk appears.
Flags: blocking1.6? → blocking1.6-

    
    

    
  
I have this same problem with Mozilla 1.5 at high resolutions (1600x1200 and
1920x1440).  However, resizing the window down to something close to 1024x768
and refreshing the page gives me a properly rendered page.  Which I can then
full-screen and maintain a cleanly rendered page.

HOWEVER, refreshing after that results in an incorrectly rendered page again. 
And not just intermittently.  ALL THE TIME.

The only variable is how much the "body" of the page is going to overlap the
sidebar (a little, a lot, or entirely).

OS: Windows 2000 SP4
Browser: Mozilla 1.5
Resolution: 1600x1200 and 1920x1440
Graphics Card: nVidia GeForce3
Driver Rev: 6.14.01.4345

    
    

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

    
    

    
  
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115 Firebird/0.7+
(.:MrC:.)

I finally experienced this bug when loading a Slashdot page. Popped up as
described by so many others, with the left-hand column covering the entire
screen. A page refresh fixed the problem. Apparently the bug is still present.

/me wonders when they'll implement that free makeover.....

    
    

    
  
Sorry for bugspam, but I also saved the page using the File->Save Page As
dialog, in case the page itself might yield any clues.

    
  
Keywords: testcase

    
    

    
  
I've just pulled a nightly of Mozilla, instead of Firefox and so far have not
been able to make it show this problem on either www.tikiwiki.org, or on my own
private tikiwiki site

    
    

    
  
Comment 42 is not relevant to this bug (which still exists).

    
    

    
  
Indeed - this bug is still present and still corrupts Slashdot quite regularly.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040211 Firebird/0.8.0+
(daihard: XFT+GTK2; optimized for P4/SSE-2)

    
    

    
  
I can confirm as well.
Moz 1.7a on Win2K

http://bugzilla.mozilla.org/show_bug.cgi?id=217527#c6 is my experience as well

    
    

    
  
When I get the overlap bug, adjusting text size (a quick ctrl+, ctrl-) seems to
fix it, and this works for the mostly-simplified and simpler-still testcases.

    
    

    
  
I noticed proxomitron causes this problem for me. Put slashdot into bypass list
and the problem goes away. Or at least it's much less frequent. 

    
    

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

    
    

    
  

      
      
      
      

        Attached patch
          
          
        hack
        — 
          — Splinter Review
      

    


  
I believe the float mew is not properly updated when the mew > available width,
the inner table is then reflowed with the mew as the available with but the
floater mew is not updated.

This hack is only provided to demonstrate where things IMHO go wrong, I'cant
claim that I know thats the right thing to do.

nb: seeing bug 13553 is really touching for me, I already asked in 2001 to
update the mew and it was one of my first patches. :-)

    
    

    
  
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040408 Firefox/0.8.0+
(daihard: XFT+GTK2; opt. for P4/SSE-2)

Ugh. This is starting to happen again on Slashdot. Same level of irreproductibility.

    
  
Blocks: 241820

    
    

    
  
I'm using 1.7b and this is now REALLY starting to annoy me. It is definitely
getting worse and is happening on almost every story page on Slashdot.
If I save the file to disk (Save page as) and open it from the file menu, it
displays correctly.

    
    

    
  
Comment on attachment 145180 [details] [diff] [review]
hack

This patch reverses a change from dbarons checkin
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&r
oot=/cvsroot&subdir=mozilla/layout/html/base/src&command=DIFF&root=/cvsroot&fil
e=nsBlockFrame.cpp&rev1=3.561&rev2=3.562#11

        Attachment #145180 -
        Flags: superreview?(dbaron)

        Attachment #145180 -
        Flags: review?(dbaron)

    
    

    
  
Does it work if you readd the if(...GetFlag...) around the
aState.UpdateMaxElementWidth so that if the flag isn't set it only stores it in
the float cache?

    
    

    
  
No, one needs to update the MEW. David, as this touches bug 186593 this is soo
your field and I don't understand why you did change that in the first place.

    
    

    
  
I don't understand why the value matters if the caller didn't ask for it.

    
    

    
  
Comment on attachment 145180 [details] [diff] [review]
hack

This makes little sense to me, and it's probably covering up something else,
but check it in.

        Attachment #145180 -
        Flags: superreview?(dbaron)

        Attachment #145180 -
        Flags: superreview+

        Attachment #145180 -
        Flags: review?(dbaron)

        Attachment #145180 -
        Flags: review+

    
    

    
  
All other calls to UpdateMaxElementWidth are conditional on the flag, so it
should really never be set to anything nonzero if the flag isn't set.  Are you
sure you understood my question in comment 53 correctly?

    
    

    
  
Comment on attachment 145180 [details] [diff] [review]
hack

I changed my mind.  It's incorrect to call UpdateMaxElementWidth on a block
reflow state that doesn't have the BRS_COMPUTEMAXELEMENTWIDTH flag set, and
there should be an assertion to that effect.

        Attachment #145180 -
        Flags: superreview-

        Attachment #145180 -
        Flags: superreview+

        Attachment #145180 -
        Flags: review-

        Attachment #145180 -
        Flags: review+

        Attachment #145180 -
        Flags: approval1.7?

    
    

    
  
The real problem is probably something wrong with the code in
nsBlockFrame::PlaceLine in the case that skips nsBlockFrame::PostPlaceLine.

    
    

    
  
(In reply to comment #57)
> Are you sure you understood my question in comment 53 correctly?

Never mind that.  I tested it, and it's true that that's required to fix the
bug.   But I have no idea why, since I can't find anything that even reads the
variable that this changes in this case.

    
    

    
  
(Well, actually, the reason for that is probably that we're going through the
codepath in nsBlockFrame::ReflowLine that calls ReflowInlineFrames twice, and
tweaks the flag in question.  But why wouldn't the MEW get set correctly the
first time through?)

    
    

    
  
Oh, that's because we throw away all the old float-related information as the
first line of nsBlockFrame::DoReflowInlineFrames.  This means the codepath
mentioned in comment 61 is broken.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch
        — 
          — Splinter Review
      

    


  
If the comment (removed in this patch) explaining why I shouldn't do this were
actually written coherently, I'd be a little more afraid of doing it.
Assignee: core.layout.tables → dbaron
Whiteboard: [patch]

    
    

    
  
>It's incorrect to call UpdateMaxElementWidth on a block
>reflow state that doesn't have the BRS_COMPUTEMAXELEMENTWIDTH flag set, and
>there should be an assertion to that effect.

OK, but could you explain me ( just to get an understanding what is going on) 
why we have there  computeMaxElementWidth introduced in bug 59200 that is also
set when we have an auto width. Is that the floater cache?

nb: I am pretty happy that you took that bug, thats floater mew buisiness is scary.

    
    

    
  
The computeMaxElementWidth is because there are two reasons we need to know it:
 (a) the parent needs to know it, or
 (b) the frame itself needs to know it, to help deal with 'auto' width.
This doesn't contradict comment 58 in any way.

When only (b) is true, we shouldn't bother telling the parent what it is.

    
    

    
  

      
      
      
      

        Attached image
          
        same idea
        — 
      

    


  
firefox .8 - this happens alot with firefox on slashdot on my win 2k machine.

        Attachment #147334 -
        Flags: superreview?(roc)

        Attachment #147334 -
        Flags: review?(bernd.mielke)

        Attachment #147334 -
        Flags: review?(bernd.mielke) → review?(roc)

    
    

    
  
I see this behaviour on firefox 0.8 under both linux and windows 2000.

    
    

    
  
Please stop with the "me too" comments in this bug. The developers are fully
aware that it hasn't been fixed, that's why it's still open. More confirmations,
screen shots, etc. aren't going to help. Thanks.

    
    

    
  
Comment on attachment 147334 [details] [diff] [review]
patch

I don't understand the comment either. At worst we'll encounter a regression
and replace the comment with a legible explanation :-)

        Attachment #147334 -
        Flags: superreview?(roc)

        Attachment #147334 -
        Flags: superreview+

        Attachment #147334 -
        Flags: review?(roc)

        Attachment #147334 -
        Flags: review+

    
    

    
  
Don't know if it helps (because you seem to be aware that it is a bug related to
reflow, or how you call it), but I get this error nearly _every_ time I load
slashdot and some other pages like the apple subsection of slashdot when I'm on
a slow connection (approx. 7.5 kb/s). I nearly never have that problem on fast
lines (full 100 MBit/s). It also does never occur when using the "go forward" or
"go backward" buttons -- except when mozilla reloads the page.

    
    

    
  
Fix checked in to trunk, 2004-05-31 10:41 -0700.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8alpha2

    
    

    
  
Fix works. But I would like to see it in 1.7. It's not in rc3.

    
    

    
  
is it possible to include this in 1.7? or is it to high risk? maybe it needs to
bake more? anyway, requesting blockage of 1.7 for this pretty visible and
annoying layout regression.

    
    

    
  
ooops, forgot to set the flag.
Flags: blocking1.7?

    
    

    
  
Too late for 1.7 since no one's put this through the layout regression tests
with a branch build. Maybe 1.7.1 if between now and then someone puts this
through the tests.
Flags: blocking1.7? → blocking1.7-

    
    

    
  
Comment on attachment 147334 [details] [diff] [review]
patch

OK, I just ran regression tests for this, so I am comfortable putting this on
the branch.  (The only thing that showed up was noise.)

        Attachment #147334 -
        Flags: approval1.7?

    
    

    
  
Comment on attachment 147334 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to 1.7

        Attachment #147334 -
        Flags: approval1.7? → approval1.7+

    
    

    
  
Fix checked in to MOZILLA_1_7_BRANCH, 2004-06-10 17:29 -0700.
Keywords: fixed1.7

    
  
Whiteboard: [patch] → needed-aviary1.0

    
  
Whiteboard: needed-aviary1.0 → fixed-aviary1.0

    
    

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

    
    

    
  
Backed out of MOZILLA_1_7_BRANCH due to bug 246382 (since we don't know how many
sites it affects).
Keywords: fixed1.7
Whiteboard: fixed-aviary1.0 → needed-aviary1.0

    
    

    
  
backed out of the aviary1.0 branch
Whiteboard: needed-aviary1.0

    
    

    
  
Please reset the status, this fix isn't working as expected and is backed out(?)
Some sites don't render correctly anymore:
http://bugzilla.mozilla.org/show_bug.cgi?id=246382

    
    

    
  
The status is correct.  It hasn't been backed out of the trunk.  See the 2
comments before yours.

    
    

    
  
Maybe we should really use a "hack" in the meanwhile: isn't it possible to
selectively disable the reflow thing for known problematic sites like slashdot?

    
    

    
  
Comment on attachment 147334 [details] [diff] [review]
patch


Asa (or any driver):
Could you change the approval1.7+ flag to '-' (or unset it), to get the bug off
the radar ?

It was "Backed out of MOZILLA_1_7_BRANCH due to bug 246382" (comment 80) !

    
    

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

    
    

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

    
    

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

    
    

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

    
  
Alias: slashdot

    
  
Flags: blocking-aviary1.0?

    
    

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

    
    

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

    
    

    
  
Are there any scripts available that insert 'print' commands into a source tree
in order to log program execution? 'Conventional' debugging seems not to work
here, right?

    
    

    
  
This isn't the place to ask general questions, and I'm not sure which debugging
you mean by "here" - they already figured out the problem and fixed it.

    
    

    
  
(In reply to comment #93)
> This isn't the place to ask general questions, and I'm not sure which debugging
> you mean by "here" - they already figured out the problem and fixed it.

Really, It looks like the fix is an improvement (if it's in firefox 9), but the
problem is still there, although a lot less frequent.

    
    

    
  
This fix isn't in Firefox 0.9 (or 0.9.x).

The fix is currently only in trunk builds, because fixing this problem caused
another problem (bug 246382). It might be possible to get this fix into future
Firefox releases, but that rather depends on fixing the other problem.

Please read all the comments in a bug before adding anything. If you have any
questions, people will be happy to answer them in the forums.

    
    

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

    
    

    
  
Erich - yes, same issue I think. The issue is the main body text not being where
it should - either too far to the left or the right, and on the main stories
page or the comment pages.

    
    

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

    
    

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

    
    

    
  
I have had the same problem now, with the lastest builds it's gotten a lot
worse. So I set about to find a fix.
A long time ago I messed around with about:config. Changing the values below,
fixed my problems like the one in:
http://bugzilla.mozilla.org/attachment.cgi?id=154064&action=view

content.notify.backoffcount 10
content.notify.interval 120000
content.notify.ontimer on
nglayout.initialpaint.delay 250

I think those were all it took. I hope it helps someone, as it did me :)

    
    

    
  
I can confirm I am still having this problem in the latest builds and it takes
alot more then one refresh now to fix it.  I sometimes have to refresh up to 5
times to have the page render correctly.

    
    

    
  
This is also happening to me to, about 20% of the time that I visit Slashdot. 
Occurs under both Mozilla 1.7.2 and Firefox 0.9.3 (Debian/GNU Linux Unstable on
x86).

    
  
Flags: blocking1.6-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-

    
    

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

    
    

    
  
Firefox is displaying serious rendering errors with Slashdot. I'm not too sure
if the fix for the bug was backed out since I am using the following build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040902
Firefox/1.0 PR (NOT FINAL)

Its the aviary branch build. 

Some comments about the behavior of the bug on my side - it only appeared upon
the first visit. Upon visiting another page and then pressing the Back button to
go back to the Slashdot page, the layout was rendered correctly. 

Similar behaviour is displayed with the Forward button. i.e. reloading page from
cache == correct layout rendering? 
Flags: blocking-aviary1.0mac+
Flags: blocking-aviary1.0-
Flags: blocking-aviary1.0+

    
    

    
  
Yong Zheng Yu please do not change flags that are set by Component Owners or
Mozilla.org people!

...Reverting the changes made by Yu.

Flags: blocking-aviary1.0mac+
Flags: blocking-aviary1.0-
Flags: blocking-aviary1.0+

    
    

    
  
This problem really exists. It is not resolved yet. Yes, really. Please reopen
the bug. I'm sure you do not want this problem in official Firefox 1.0.
Flags: blocking-aviary1.0- → blocking-aviary1.0+

    
    

    
  
The problem is fixed on the trunk, which is why the status says "fixed". It is
known not to be fixed on the Firefox 1.0 branch or Mozilla 1.7 branch (which is
clear if you read the previous comments).

Don't change the flags unless you're authorised to do so.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-

    
    

    
  
If you really meant Mozilla 1.7 then:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4

still has the problem (minor). Back,Forward renders differently at least (and
seems correct after this).

If you meant 1.8 branch, then ok, I hope it is really fixed.

And I really didn't change flags ... must be browser submitting previous state
(whis was blocking-aviary1.0+ for some time after someone changed it).

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
Can someone in the know explain what 'fixed in the trunk' means ? There doesn't
appear to be a jargon dictionary link for bugzilla on this page... and I'm not
sure what that phrase is trying to say.


    
    

    
  
google for mozilla jargon gives http://www.mozilla.org/docs/jargon.html
In short: trunk is the main  developement effort. From the trunk branches
spinoff  very often for releases. This is done to get the release more stable
and not affected by bleeding edge developements. In this case Firefox is on a
branch for the 1.0 release. So this bug is not fixed on the FF 1.0 release
branch but on the main developement trunk. So if you download a Seamonkey
nightly you will see this bug fixed, but if you use a FF branch build than it is
not. FF will pickup this change after the release when the developement returns
to the main trunk. http://www.mozilla.org/roadmap.html#milestone-schedule is
graphical representation of the situation. 

    
    

    
  
Isn't the point of Firefox finally reaching release 1.0 that we now have a
stable version that we can recommend to our friends who want something that
works and aren't prepared to accept the bugs of the pre-1.0 versions?  If so,
then how can Firefox 1.0 ship with a bug a major as this?

    
    

    
  
Although I agree with you, I don't think that anything can be done about that.

I also work in an environment with rather tight change control, and I suspect
that's what is going on here too. The 1.0 branch would have split off before
this bug was fixed, and they don't want to risk introducing another bug into the
release candidate by applying patches that were developed after that split occured.

    
    

    
  
In theory this could land on the branch -- except there really aren't enough
people doing organized layout testing.  Bug 246999 fixed the main regression
that this caused -- but I think it may have caused some regressions itself.  I
saw some bugs that looked like they were regressions not long after it landed. 
If enough people were triaging layout bugs -- which means both simplifying
testcases and (more importantly for this) identifying when regressions happened
and what caused them, we might be able to identify and fix the regressions in
order to get the fixes onto the branch.  At this point it may be too late to do
that, though.  However, there aren't enough people looking at layout bugs now to
get a good sense of what regressions may have resulted from the patch to bug 246999.

    
    

    
  
To support David's opppinion, one regression that is not fixed yet is bug 257955.

    
    

    
  
It looks like bug #254943 is a recent duplicate of this, but being quite new I
can't indicate it as such.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
The problem usually gets worse if I'm logged into Slashdot.

See screenshots of Firefox 1.0PR:

Problem seen...
...while logged into Slashdot: http://brew-masters.com/node/view/199
...while NOT logged into Slashdot: http://brew-masters.com/node/view/198

Problem NOT seen...
...while logged into Slashdot: http://brew-masters.com/node/view/201
...while NOT logged into Slashdot: http://brew-masters.com/node/view/200

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
(In reply to comment #129)
> *** Bug 264913 has been marked as a duplicate of this bug. ***

Bug 264913 is *not* a dupe of this bug.  As seen in this screenshot
(https://bugzilla.mozilla.org/attachment.cgi?id=154064&action=view), this is not
the rendering problem with the left column overlapping, this is the story being
COMPLETELY off the page (the comment box on the "post" pages).  If this is the
same problem, forgive me, but I'm using PR .10 and the column bug is gone, but
the story bug is not.  



    
    

    
  
Adam -- the problem shown in that screenshot _is_ solved in the patch for this
bug. I've applied it to my own rebuilds of the PR release, and slashdot is now
fine. Well, as fine as it ever was.

    
    

    
  
This is not fixed.. Using FireFox 1.0 RC1

Screenshot:
http://www.pecknology.net/storage/wtf.jpg

    
    

    
  
(In reply to comment #132)
> This is not fixed.. Using FireFox 1.0 RC1
> 
> Screenshot:
> http://www.pecknology.net/storage/wtf.jpg

Please see comment 108.
Adding Whiteboard comment to clarify situation.



Whiteboard: Fixed on trunk, but not [yet] on aviary or 1.7 branch
Whiteboard: Fixed on trunk, but not [yet] on aviary or 1.7 branch → See comments 95 and 108. Fixed on trunk, but not on aviary or 1.7 branch.

    
    

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

    
    

    
  


  
You may notice that the screenshot posted on 2004-07-22 22:17 PDT has scroll
bars at the bottom. The page seems to be a slighty more than twice the normal
width. This screenshot is what you'd see if you scrolled fully to the right.

    
    

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

    
    

    
  
So the problem that got this backed out of 1.7 and aviary is apparently fixed in
bug 226637. Are there plans to put this into aviary 1.1?

    
    

    
  
Firefox 1.1 will be based on a new branch from the trunk, so it will have
everything the current trunk has, including this fix.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
I am deeply, deeply sorry for starting up again this subject, but honestly
believe it is NOT fixed. I have read through several stories claiming that
either Firefox has the problem fixed somehow, or that Slashdot have changed
their layout to avoid the issue, and everything indeed appeared to work fine for
at least the last two months, but: for a few days I was browsing in some
long-forgotten conditions - slow links with high latency (GSM GPRS and an
equivalent from a local mobile provider www.zapp.ro, don't have the slightest
clue how their phones function, but linux sees them as a regular PPP connection
with no custom kernel modules). Four out of five times now, the Slashdot page is
rendered incorrectly (can fix with Ctrl+Ctrl-), but not just that one.
Userfriendly.org has some elements moved a few pixels up/to the left/etc,
miami.com has pieces of text overlapping. These are the sites I can surely
reproduce the misalignment behaviour, and am also sure none of these problems
appears on a fast cable connection.
FF 1.0 from linuxpackages.net, Slackware 10.0

    
    

    
  
********************************************************

THIS PROBLEM IS FIXED, BUT THE FIX IS NOT IN FIREFOX 1.0

       BE PATIENT: FIREFOX 1.1 *WILL* HAVE IT.

       Or, try a nightly trunk build instead.

********************************************************

    
    

    
  
for those with FF 1.0: try this extension for a workaround
http://hardgrok.org/blog/item/slashfix-firefox-extension.html

    
    

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

    
    

    
  
Is the behaviour on http://www.dtr.isy.liu.se/en related to this bug? The left
column is overlapped by the right on the first load (or with a cleared cache),
but every load after that displays correctly. Oddly enough, no button reload
helps - a "enter" hit in the address bar is required.

    
    

    
  
Jakob: No - I haven't closely looked into what's happening there, but it doesn't
get fixed by refreshing and it still happens in current trunk builds which have
the fix for this issue, so it's not the same bug.

This is definitely fixed.
Status: RESOLVED → VERIFIED

    
    

    
  
(In reply to comment #148)
> Is the behaviour on http://www.dtr.isy.liu.se/en related to this bug?

Yes, same bug.  

If you create a bookmark and set the location as this entire piece: 
javascript:(function(){var s=document.body.style; var x=s.display;
s.display='none'; s.display=x;})()

You can load this on any "broken" Slashdot page and it will immediately fix
itself.  By running my "Slashdot fix" bookmark in FF 1.0 on the above page, it
is immediately fixed.  If you upgrade to one of the nightlies, which have been
mostly stable for me, you should see the bug is fixed there too.  Alternatively,
wait for FF 1.1, which, if anything, I'm excited about just to termite this damn
bug emailing me twice a week.  :)    

    
    

    
  
Doh - ok, so that site is having some kind of reflow issue, contrary to what I
just said - refreshing does fix it (dunno what I did the first time I tried). 
However, the issue with that page is definitely not fixed in current trunk
builds, so it's still not the same bug as this.

    
    

    
  
(In reply to comment #150)
> If you create a bookmark and set the location as this entire piece: 
> javascript:(function(){var s=document.body.style; var x=s.display;
> s.display='none'; s.display=x;})()

I do not see this as fixing slashdot.org. I copied and pasted and made sure all
was in the way it was here.

    
    

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

    
    

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

    
    

    
  
Greetings,

I'm trying to determine whether I am getting bitten by this bug on a site I'm
developing. I gather from the patch & comments that the issue is with the
computation of max-element-width for floats, possibly related to tables. Would
it be possible to get a web-author-level explanation of what this means? That
would help me isolate it in my case, and possibly work around it.

I did look at the test cases, but I certainly don't have this on any of my pages:

  <script type="text/javascript">var foo = document.body.offsetHeight;</script>

;-)

Thanks!



chad

    
    

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

    
    

    
  
I have never seen this error on slashdot, I first started using firefox at
version 0.9.3, and still have yet to see this bug...

    
    

    
  
I used to see it all the time, since 0.7 if I recall, but stopped seeing it
since I started using the SlashFix extension.  I doubt it's an issue anymore,
though, since /. just switched to HTML 4+CSS.  Amusing that Slashdot provided a
solution before it was fixed in FF, especially since it's been around for so
long.  I appreciate priorities, but many Slashdot users are major promoters of
FF and the MoFo, so it always seemed odd that it wasn't higher on the list, IMHO.

    
    

    
  
It isn't just slashdot that suffered from this problem, though slashdot may have
been the most common and visible victim.

I use Horde IMP (www.horde.org) for web mail, and see this problem on a daily
basis. The Imp forums have numerous entries explaining this and pointing to this
bug report.

    
    

    
  
Removing myself from the CC list.
Depends on: 334970

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: