Last Comment Bug 217527 - (slashdot) {inc}left column on slashdot is sometimes too narrow or too wide for its contents
(slashdot)
: {inc}left column on slashdot is sometimes too narrow or too wide for its cont...
Status: VERIFIED FIXED
See comments 95 and 108. Fixed on tru...
: testcase
Product: Core
Classification: Components
Component: Layout: Tables (show other bugs)
: Trunk
: All All
: -- normal with 26 votes (vote)
: mozilla1.8alpha2
Assigned To: David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
: Madhur Bhatia
Mentors:
http://www.slashdot.org
: 213346 220569 221010 222362 229758 238922 242142 244781 247264 247438 247784 249309 249876 252699 252982 253685 254943 256551 258221 258620 258894 258899 260030 260256 260666 261653 264127 264360 265661 269977 270344 271994 272300 272390 272614 274103 284463 284946 291392 (view as bug list)
Depends on: 334970
Blocks: 241820
  Show dependency treegraph
 
Reported: 2003-08-27 19:18 PDT by Robert Accettura [:raccettura]
Modified: 2014-04-26 03:20 PDT (History)
72 users (show)
asa: blocking1.7-
michaell+bmo: blocking‑aviary1.0-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Screenshot of problem (212.60 KB, image/png)
2003-08-27 19:19 PDT, Robert Accettura [:raccettura]
no flags Details
Save Page As ... of a Slashot comments page that displayed with no text when loaded from Slashdot (40.54 KB, application/octet-stream)
2003-10-18 06:38 PDT, Thomas Holaday
no flags Details
mostly simplified testcase (807 bytes, text/html; charset=UTF-8)
2003-12-11 15:15 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details
slightly simpler testcase (641 bytes, text/html; charset=UTF-8)
2003-12-11 15:17 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details
simpler still (537 bytes, text/html; charset=UTF-8)
2003-12-11 15:31 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details
reflow log (9.10 KB, text/plain)
2003-12-13 09:09 PST, Bernd
no flags Details
reflow log for attachment 137272 (8.43 KB, text/plain)
2003-12-18 15:05 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details
hack (1.24 KB, patch)
2004-03-31 08:42 PST, Bernd
dbaron: review-
dbaron: superreview-
Details | Diff | Review
patch (2.31 KB, patch)
2004-04-29 12:55 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
roc: review+
roc: superreview+
Details | Diff | Review
same idea (137.03 KB, image/pjpeg)
2004-05-07 06:36 PDT, Ross Charette
no flags Details
Is this the same bug? it doesn't look like the other posted problems (239.57 KB, image/png)
2004-07-22 22:17 PDT, Erich Hoover
no flags Details
The "scrolled to the right" view of the above screenshot (154.81 KB, image/png)
2004-11-09 10:02 PST, Justin
no flags Details

Description Robert Accettura [:raccettura] 2003-08-27 19:18:55 PDT
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
Comment 1 Robert Accettura [:raccettura] 2003-08-27 19:19:32 PDT
Created attachment 130498 [details]
Screenshot of problem
Comment 2 Bernard Alleysson 2003-08-31 19:28:29 PDT
WFM windows 2003 mozilla 1.5b
Comment 3 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-28 11:28:32 PDT
*** Bug 220569 has been marked as a duplicate of this bug. ***
Comment 4 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-28 11:29:24 PDT
I've seen this as well, on Linux.
Comment 5 Jim Davis 2003-09-28 13:04:21 PDT
(Sorry about the dupe--I swear, I searched for "/\." and "slashdot" more than
once each!)
Comment 6 Stewart Johnson 2003-10-02 20:49:06 PDT
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. :/
Comment 7 dave 2003-10-10 19:52:41 PDT
Everything the guy above said, except I'm on WinXP
Comment 8 Damian Yerrick 2003-10-14 17:03:31 PDT
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?
Comment 9 Oleg Sidletskiy 2003-10-15 21:30:53 PDT
*** Bug 221010 has been marked as a duplicate of this bug. ***
Comment 10 Oleg Sidletskiy 2003-10-15 21:31:28 PDT
*** Bug 222362 has been marked as a duplicate of this bug. ***
Comment 11 George Kennedy 2003-10-17 16:24:54 PDT
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
Comment 12 Thomas Holaday 2003-10-18 06:38:26 PDT
Created attachment 133570 [details]
Save Page As ... of a Slashot comments page that displayed with no text when loaded from Slashdot
Comment 13 Thomas Holaday 2003-10-18 06:39:50 PDT
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.
Comment 14 jeff putnam 2003-10-23 08:45:43 PDT
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. 
Comment 15 Doron Rosenberg (IBM) 2003-11-12 11:12:36 PST
I'm seeing comment 6 a lot on slashdot.  Changing the paint delay to a large
value seems to make it not happen anymore.
Comment 16 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-11-22 22:12:20 PST
There's a chance the patch to bug 215857 will fix this, although I suspect not.
Comment 17 tor 2003-11-25 11:21:42 PST
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]
Comment 18 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-11-25 11:33:40 PST
Not related (unless the problem goes away on repaint, which I don't think it
does).  Please file a separate bug.
Comment 19 Bernd 2003-11-26 12:31:24 PST
I filed bug 226870
Comment 20 Jorrit Tyberghein 2003-12-10 01:48:25 PST
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 
Comment 21 Jorrit Tyberghein 2003-12-10 07:33:58 PST
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
Comment 22 chris hofmann 2003-12-10 17:05:00 PST
dbaron will have a look
Comment 23 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-12-11 15:15:57 PST
Created attachment 137269 [details]
mostly simplified testcase
Comment 24 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-12-11 15:17:24 PST
Created attachment 137270 [details]
slightly simpler testcase

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.
Comment 25 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-12-11 15:24:27 PST
I suspect this is roughly the same problem as bug 215857, but for floats being
part of max element width.
Comment 26 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-12-11 15:31:34 PST
Created attachment 137272 [details]
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.
Comment 27 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-12-11 15:34:24 PST
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.
Comment 28 Bernd 2003-12-13 09:09:51 PST
Created attachment 137359 [details]
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
Comment 29 Bernd 2003-12-13 09:27:00 PST
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.
Comment 30 Bernd 2003-12-14 22:19:07 PST
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 31 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-12-18 14:01:53 PST
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.
Comment 32 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-12-18 15:05:34 PST
Created attachment 137675 [details]
reflow log for attachment 137272 [details]

This is the reflow log I see, which disagrees with attachment 137359 [details] and agrees
more with the other comments.
Comment 33 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-12-21 19:41:41 PST
Comment on attachment 137272 [details]
simpler still

The behavior on this testcase regressed between mozilla1.0 and mozilla1.0.1.
Comment 34 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-12-21 19:48:21 PST
...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.
Comment 35 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-12-21 19:53:22 PST
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].
Comment 36 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-12-30 19:36:43 PST
*** Bug 229758 has been marked as a duplicate of this bug. ***
Comment 37 chris hofmann 2004-01-06 17:07:42 PST
need to 1.6- for now.  lets get a patch for the trunk and renominate if
something low risk appears.
Comment 38 Charles Borner 2004-01-10 22:30:08 PST
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
Comment 39 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-01-15 10:38:47 PST
*** Bug 213346 has been marked as a duplicate of this bug. ***
Comment 40 Bradley Chapman (not reading bugmail, still gone but not forever) 2004-01-18 14:35:04 PST
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.....
Comment 41 Bradley Chapman (not reading bugmail, still gone but not forever) 2004-01-18 14:37:29 PST
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.
Comment 42 Robert Goldman 2004-02-13 13:55:33 PST
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 43 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-02-13 14:02:40 PST
Comment 42 is not relevant to this bug (which still exists).
Comment 44 Bradley Chapman (not reading bugmail, still gone but not forever) 2004-02-13 16:05:35 PST
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)
Comment 45 darren kruse 2004-02-21 04:29:54 PST
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
Comment 46 Jim Davis 2004-03-05 07:01:43 PST
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.
Comment 47 Olli Männistö 2004-03-29 14:46:18 PST
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. 
Comment 48 Jeff Walden [:Waldo] (remove +bmo to email) 2004-03-30 11:47:40 PST
*** Bug 238922 has been marked as a duplicate of this bug. ***
Comment 49 Bernd 2004-03-31 08:42:25 PST
Created attachment 145180 [details] [diff] [review]
hack

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. :-)
Comment 50 Bradley Chapman (not reading bugmail, still gone but not forever) 2004-04-15 10:58:33 PDT
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.
Comment 51 Jeremy 2004-04-28 18:11:45 PDT
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 52 Bernd 2004-04-29 09:09:53 PDT
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
Comment 53 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-04-29 09:19:25 PDT
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?
Comment 54 Bernd 2004-04-29 11:29:50 PDT
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.
Comment 55 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-04-29 11:47:41 PDT
I don't understand why the value matters if the caller didn't ask for it.
Comment 56 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-04-29 11:48:29 PDT
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.
Comment 57 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-04-29 11:51:45 PDT
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 58 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-04-29 11:52:24 PDT
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.
Comment 59 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-04-29 12:28:26 PDT
The real problem is probably something wrong with the code in
nsBlockFrame::PlaceLine in the case that skips nsBlockFrame::PostPlaceLine.
Comment 60 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-04-29 12:39:30 PDT
(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.
Comment 61 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-04-29 12:41:16 PDT
(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?)
Comment 62 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-04-29 12:50:44 PDT
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.
Comment 63 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-04-29 12:55:14 PDT
Created attachment 147334 [details] [diff] [review]
patch

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.
Comment 64 Bernd 2004-04-29 13:50:44 PDT
>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.
Comment 65 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-04-29 14:08:28 PDT
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.
Comment 66 Ross Charette 2004-05-07 06:36:34 PDT
Created attachment 147890 [details]
same idea

firefox .8 - this happens alot with firefox on slashdot on my win 2k machine.
Comment 67 Murray Barton 2004-05-11 00:07:30 PDT
I see this behaviour on firefox 0.8 under both linux and windows 2000.
Comment 68 Jon Henry 2004-05-11 08:44:55 PDT
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 69 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-05-14 21:36:16 PDT
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 :-)
Comment 70 Mark Stier 2004-05-31 04:25:44 PDT
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.
Comment 71 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-05-31 10:42:36 PDT
Fix checked in to trunk, 2004-05-31 10:41 -0700.
Comment 72 Mark Stier 2004-06-09 06:41:17 PDT
Fix works. But I would like to see it in 1.7. It's not in rc3.
Comment 73 Kai de Leeuw 2004-06-09 12:55:11 PDT
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.
Comment 74 Kai de Leeuw 2004-06-09 12:57:17 PDT
ooops, forgot to set the flag.
Comment 75 Asa Dotzler [:asa] 2004-06-10 12:28:50 PDT
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.
Comment 76 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-06-10 16:56:28 PDT
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.)
Comment 77 Asa Dotzler [:asa] 2004-06-10 17:24:43 PDT
Comment on attachment 147334 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to 1.7
Comment 78 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-06-10 17:31:04 PDT
Fix checked in to MOZILLA_1_7_BRANCH, 2004-06-10 17:29 -0700.
Comment 79 Michael Lefevre 2004-06-11 04:48:08 PDT
*** Bug 242142 has been marked as a duplicate of this bug. ***
Comment 80 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-06-11 12:32:22 PDT
Backed out of MOZILLA_1_7_BRANCH due to bug 246382 (since we don't know how many
sites it affects).
Comment 81 Scott MacGregor 2004-06-11 12:54:26 PDT
backed out of the aviary1.0 branch
Comment 82 Ger Teunis 2004-06-11 14:05:16 PDT
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
Comment 83 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-06-11 14:35:54 PDT
The status is correct.  It hasn't been backed out of the trunk.  See the 2
comments before yours.
Comment 84 Mark Stier 2004-06-15 16:36:37 PDT
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 85 Serge Gautherie (:sgautherie) 2004-06-16 16:14:10 PDT
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) !
Comment 86 Michael Lefevre 2004-06-17 06:04:11 PDT
*** Bug 244781 has been marked as a duplicate of this bug. ***
Comment 87 Michael Lefevre 2004-06-17 06:08:04 PDT
*** Bug 247264 has been marked as a duplicate of this bug. ***
Comment 88 José Jeria 2004-06-17 23:18:28 PDT
*** Bug 247438 has been marked as a duplicate of this bug. ***
Comment 89 Olivier Cahagne 2004-06-20 06:06:09 PDT
*** Bug 247784 has been marked as a duplicate of this bug. ***
Comment 90 PikeUK 2004-07-02 13:20:11 PDT
*** Bug 249309 has been marked as a duplicate of this bug. ***
Comment 91 Aaron Kaluszka 2004-07-05 10:51:28 PDT
*** Bug 249876 has been marked as a duplicate of this bug. ***
Comment 92 Mark Stier 2004-07-08 05:44:37 PDT
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?
Comment 93 Michael Lefevre 2004-07-08 05:49:29 PDT
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.
Comment 94 Chris Robinson 2004-07-08 06:55:58 PDT
(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.
Comment 95 Michael Lefevre 2004-07-08 07:11:48 PDT
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.
Comment 96 Ryan Polk (Quark) 2004-07-22 16:14:43 PDT
*** Bug 252699 has been marked as a duplicate of this bug. ***
Comment 97 Erich Hoover 2004-07-22 22:17:18 PDT
Created attachment 154064 [details]
Is this the same bug? it doesn't look like the other posted problems
Comment 98 Michael Lefevre 2004-07-23 02:06:52 PDT
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.
Comment 99 R.K.Aa. 2004-07-25 07:34:22 PDT
*** Bug 252982 has been marked as a duplicate of this bug. ***
Comment 100 Mats Palmgren (:mats) 2004-07-30 07:20:08 PDT
*** Bug 253685 has been marked as a duplicate of this bug. ***
Comment 101 Lars Petersen 2004-07-30 08:42:19 PDT
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 :)
Comment 102 Justin Lintz 2004-07-30 10:21:28 PDT
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.
Comment 103 Luke Reeves 2004-08-11 08:34:40 PDT
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).
Comment 104 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-08-22 19:52:04 PDT
*** Bug 256551 has been marked as a duplicate of this bug. ***
Comment 105 Yong Zheng Yu 2004-09-03 02:56:52 PDT
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? 
Comment 106 Patrick 2004-09-03 03:11:44 PDT
Yong Zheng Yu please do not change flags that are set by Component Owners or
Mozilla.org people!

...Reverting the changes made by Yu.
Comment 107 Lenar Lõhmus 2004-09-03 03:18:00 PDT
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.
Comment 108 Michael Lefevre 2004-09-03 03:29:07 PDT
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.
Comment 109 Lenar Lõhmus 2004-09-03 03:54:58 PDT
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).
Comment 110 Ryan Polk (Quark) 2004-09-06 18:59:10 PDT
*** Bug 258221 has been marked as a duplicate of this bug. ***
Comment 111 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2004-09-09 10:29:51 PDT
*** Bug 258620 has been marked as a duplicate of this bug. ***
Comment 112 Bill Mason 2004-09-11 16:51:34 PDT
*** Bug 258894 has been marked as a duplicate of this bug. ***
Comment 113 Bill Mason 2004-09-11 16:52:02 PDT
*** Bug 258899 has been marked as a duplicate of this bug. ***
Comment 114 Ian Batterbee 2004-09-11 17:26:19 PDT
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.
Comment 115 Bernd 2004-09-11 22:22:04 PDT
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. 
Comment 116 Brian Frink 2004-09-12 15:16:01 PDT
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?
Comment 117 Ian Batterbee 2004-09-12 15:25:29 PDT
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.
Comment 118 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-09-12 15:40:49 PDT
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.
Comment 119 Bernd 2004-09-12 21:15:37 PDT
To support David's opppinion, one regression that is not fixed yet is bug 257955.
Comment 120 Jim Warren 2004-09-15 07:20:34 PDT
It looks like bug #254943 is a recent duplicate of this, but being quite new I
can't indicate it as such.
Comment 121 Michael Lefevre 2004-09-15 07:37:01 PDT
*** Bug 254943 has been marked as a duplicate of this bug. ***
Comment 122 José Jeria 2004-09-17 08:39:48 PDT
*** Bug 260030 has been marked as a duplicate of this bug. ***
Comment 123 Bill Mason 2004-09-18 12:23:27 PDT
*** Bug 260256 has been marked as a duplicate of this bug. ***
Comment 124 José Jeria 2004-09-20 23:46:46 PDT
*** Bug 260666 has been marked as a duplicate of this bug. ***
Comment 125 Michael Mol 2004-09-21 04:53:15 PDT
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
Comment 126 Bill Mason 2004-09-26 07:42:10 PDT
*** Bug 261653 has been marked as a duplicate of this bug. ***
Comment 127 Sander 2004-10-12 21:48:08 PDT
*** Bug 264127 has been marked as a duplicate of this bug. ***
Comment 128 Ryan Polk (Quark) 2004-10-14 07:47:29 PDT
*** Bug 264360 has been marked as a duplicate of this bug. ***
Comment 129 Bill Mason 2004-10-18 09:34:23 PDT
*** Bug 264913 has been marked as a duplicate of this bug. ***
Comment 130 A S 2004-10-18 10:08:18 PDT
(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.  

Comment 131 Matthew Miller 2004-10-18 10:23:14 PDT
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.
Comment 132 Danny Peck 2004-10-28 12:14:37 PDT
This is not fixed.. Using FireFox 1.0 RC1

Screenshot:
http://www.pecknology.net/storage/wtf.jpg
Comment 133 Patrick 2004-10-28 12:24:57 PDT
(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.


Comment 134 Tony Tovar 2004-10-28 17:19:48 PDT
*** Bug 265661 has been marked as a duplicate of this bug. ***
Comment 135 Justin 2004-11-09 10:02:38 PST
Created attachment 165308 [details]
The "scrolled to the right" view of the above screenshot

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.
Comment 136 Bill Mason 2004-11-15 10:57:15 PST
*** Bug 269977 has been marked as a duplicate of this bug. ***
Comment 137 Taral 2004-11-21 09:44:25 PST
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?
Comment 138 Michael Lefevre 2004-11-21 11:20:59 PST
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.
Comment 139 Michael Lefevre 2004-11-21 11:23:10 PST
*** Bug 270344 has been marked as a duplicate of this bug. ***
Comment 140 José Jeria 2004-11-27 08:17:40 PST
*** Bug 271994 has been marked as a duplicate of this bug. ***
Comment 141 Phil Ringnalda (:philor) 2004-11-29 22:06:40 PST
*** Bug 272300 has been marked as a duplicate of this bug. ***
Comment 142 Olivier Cahagne 2004-11-30 03:06:25 PST
*** Bug 272390 has been marked as a duplicate of this bug. ***
Comment 143 Don J. Rude 2004-12-02 13:12:28 PST
*** Bug 272614 has been marked as a duplicate of this bug. ***
Comment 144 Razvan Cosma 2004-12-08 20:51:15 PST
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
Comment 145 Matthew Miller 2004-12-08 21:41:11 PST
********************************************************

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.

********************************************************
Comment 146 Matthias Wallner 2004-12-08 23:53:08 PST
for those with FF 1.0: try this extension for a workaround
http://hardgrok.org/blog/item/slashfix-firefox-extension.html
Comment 147 Jo Hermans 2004-12-10 15:31:36 PST
*** Bug 274103 has been marked as a duplicate of this bug. ***
Comment 148 Jakob Viketoft 2004-12-15 05:28:58 PST
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.
Comment 149 Michael Lefevre 2004-12-20 09:42:36 PST
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.
Comment 150 A S 2004-12-20 09:49:10 PST
(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.  :)    
Comment 151 Michael Lefevre 2004-12-20 09:53:10 PST
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.
Comment 152 Trever Adams 2004-12-20 11:09:37 PST
(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.
Comment 153 José Jeria 2005-03-02 12:01:44 PST
*** Bug 284463 has been marked as a duplicate of this bug. ***
Comment 154 Ian Meyer 2005-03-05 15:58:08 PST
*** Bug 284946 has been marked as a duplicate of this bug. ***
Comment 155 chad 2005-03-10 20:14:16 PST
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
Comment 156 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-04-21 18:00:31 PDT
*** Bug 291392 has been marked as a duplicate of this bug. ***
Comment 157 bryan986 2005-05-07 18:35:00 PDT
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...
Comment 158 Daniel M. Hendricks 2005-09-22 07:31:29 PDT
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.
Comment 159 Edward Burr 2005-09-26 06:42:48 PDT
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.
Comment 160 Michael Mol 2006-03-12 17:37:14 PST
Removing myself from the CC list.

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