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

WFM windows 2003 mozilla 1.5b

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

I've seen this as well, on Linux.

(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?

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

dbaron will have a look

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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

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

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 :-)

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.

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.

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 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 on attachment 147334 [details] [diff] [review] patch a=asa (on behalf of drivers) for checkin to 1.7

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

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

backed out of the aviary1.0 branch

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

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

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

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

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.

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.

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.

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

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