The default bug view has changed. See this FAQ.
Bug 217527 (slashdot)

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

VERIFIED FIXED in mozilla1.8alpha2

Status

()

Core
Layout: Tables
VERIFIED FIXED
14 years ago
3 years ago

People

(Reporter: raccettura, Assigned: dbaron)

Tracking

({testcase})

Trunk
mozilla1.8alpha2
testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.7 -
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(11 attachments, 1 obsolete attachment)

(Reporter)

Description

14 years ago
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
(Reporter)

Comment 1

14 years ago
Created attachment 130498 [details]
Screenshot of problem

Comment 2

14 years ago
WFM windows 2003 mozilla 1.5b
(Assignee)

Updated

14 years ago
Summary: Reloads can cause undesired table oddities → {inc}Reloads can cause undesired table oddities
(Assignee)

Comment 3

14 years ago
*** Bug 220569 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 4

14 years ago
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

Comment 5

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

Comment 6

14 years ago
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

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

Comment 8

14 years ago
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

Comment 9

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

Comment 10

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

Comment 11

14 years ago
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

14 years ago
Created attachment 133570 [details]
Save Page As ... of a Slashot comments page that displayed with no text when loaded from Slashdot

Comment 13

14 years ago
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

14 years ago
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.
(Assignee)

Comment 16

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

Comment 17

14 years ago
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]
(Assignee)

Comment 18

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

Comment 19

14 years ago
I filed bug 226870

Comment 20

14 years ago
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

14 years ago
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

Updated

14 years ago
Flags: blocking1.6?

Comment 22

14 years ago
dbaron will have a look
(Assignee)

Comment 23

14 years ago
Created attachment 137269 [details]
mostly simplified testcase
(Assignee)

Comment 24

14 years ago
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.
(Assignee)

Comment 25

14 years ago
I suspect this is roughly the same problem as bug 215857, but for floats being
part of max element width.
(Assignee)

Comment 26

14 years ago
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.
(Assignee)

Updated

14 years ago
Attachment #137270 - Attachment is obsolete: true
(Assignee)

Comment 27

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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.
(Assignee)

Updated

14 years ago
Blocks: 213346
(Assignee)

Comment 31

14 years ago
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.
(Assignee)

Comment 32

14 years ago
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.
(Assignee)

Comment 33

13 years ago
Comment on attachment 137272 [details]
simpler still

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

Comment 34

13 years ago
...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.
(Assignee)

Comment 35

13 years ago
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].
(Assignee)

Comment 36

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

Comment 37

13 years ago
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-

Comment 38

13 years ago
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
(Assignee)

Updated

13 years ago
No longer blocks: 213346
(Assignee)

Comment 39

13 years ago
*** 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.

Updated

13 years ago
Keywords: testcase

Comment 42

13 years ago
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
(Assignee)

Comment 43

13 years ago
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)

Comment 45

13 years ago
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

13 years ago
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

13 years ago
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. ***

Comment 49

13 years ago
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. :-)
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.

Updated

13 years ago
Blocks: 241820

Comment 51

13 years ago
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

13 years ago
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)
(Assignee)

Comment 53

13 years ago
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

13 years ago
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.
(Assignee)

Comment 55

13 years ago
I don't understand why the value matters if the caller didn't ask for it.
(Assignee)

Comment 56

13 years ago
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+
(Assignee)

Updated

13 years ago
Attachment #145180 - Flags: approval1.7?
(Assignee)

Comment 57

13 years ago
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?
(Assignee)

Comment 58

13 years ago
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?
(Assignee)

Comment 59

13 years ago
The real problem is probably something wrong with the code in
nsBlockFrame::PlaceLine in the case that skips nsBlockFrame::PostPlaceLine.
(Assignee)

Comment 60

13 years ago
(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.
(Assignee)

Comment 61

13 years ago
(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?)
(Assignee)

Comment 62

13 years ago
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.
(Assignee)

Comment 63

13 years ago
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.
(Assignee)

Updated

13 years ago
Assignee: core.layout.tables → dbaron
Whiteboard: [patch]

Comment 64

13 years ago
>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.
(Assignee)

Comment 65

13 years ago
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

13 years ago
Created attachment 147890 [details]
same idea

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

Updated

13 years ago
Attachment #147334 - Flags: superreview?(roc)
Attachment #147334 - Flags: review?(bernd.mielke)
(Assignee)

Updated

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

Comment 67

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

Comment 68

13 years ago
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+

Comment 70

13 years ago
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.
(Assignee)

Comment 71

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

Comment 72

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

Comment 73

13 years ago
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

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

Comment 75

13 years ago
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-
(Assignee)

Comment 76

13 years ago
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 77

13 years ago
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+
(Assignee)

Comment 78

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

Updated

13 years ago
Whiteboard: [patch] → needed-aviary1.0

Updated

13 years ago
Whiteboard: needed-aviary1.0 → fixed-aviary1.0

Comment 79

13 years ago
*** Bug 242142 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 80

13 years ago
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

Comment 81

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

Comment 82

13 years ago
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
(Assignee)

Comment 83

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

Comment 84

13 years ago
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) !
(Assignee)

Updated

13 years ago
Attachment #147334 - Flags: approval1.7+

Comment 86

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

Comment 87

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

Comment 88

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

Comment 89

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

Updated

13 years ago
Alias: slashdot

Updated

13 years ago
Flags: blocking-aviary1.0?

Comment 90

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

Comment 91

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

Comment 92

13 years ago
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

13 years ago
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

13 years ago
(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

13 years ago
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

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

Comment 97

13 years ago
Created attachment 154064 [details]
Is this the same bug? it doesn't look like the other posted problems

Comment 98

13 years ago
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

13 years ago
*** Bug 252982 has been marked as a duplicate of this bug. ***
*** Bug 253685 has been marked as a duplicate of this bug. ***

Comment 101

13 years ago
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

13 years ago
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

13 years ago
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).

Updated

13 years ago
Flags: blocking1.6-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
(Assignee)

Comment 104

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

Comment 105

13 years ago
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+

Comment 106

13 years ago
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+

Comment 107

13 years ago
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+

Comment 108

13 years ago
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-

Comment 109

13 years ago
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

13 years ago
*** Bug 258221 has been marked as a duplicate of this bug. ***
*** Bug 258620 has been marked as a duplicate of this bug. ***

Comment 112

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

Comment 113

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

Comment 114

13 years ago
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

13 years ago
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

13 years ago
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

13 years ago
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.
(Assignee)

Comment 118

13 years ago
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

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

Comment 120

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

Comment 121

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

Comment 122

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

Comment 123

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

Comment 124

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

Comment 125

13 years ago
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

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

Comment 127

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

Comment 128

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

Comment 129

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

Comment 130

13 years ago
(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

13 years ago
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

13 years ago
This is not fixed.. Using FireFox 1.0 RC1

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

Comment 133

13 years ago
(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.

Comment 134

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

Comment 135

13 years ago
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

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

Comment 137

13 years ago
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

13 years ago
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

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

Comment 140

13 years ago
*** Bug 271994 has been marked as a duplicate of this bug. ***
*** Bug 272300 has been marked as a duplicate of this bug. ***

Comment 142

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

Comment 143

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

Comment 144

13 years ago
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

13 years ago
********************************************************

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

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

Comment 147

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

Comment 148

12 years ago
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

12 years ago
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

Comment 150

12 years ago
(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

12 years ago
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

12 years ago
(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

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

Comment 154

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

Comment 155

12 years ago
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. ***

Comment 157

12 years ago
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

12 years ago
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

12 years ago
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

11 years ago
Removing myself from the CC list.

Updated

11 years ago
Depends on: 334970
You need to log in before you can comment on or make changes to this bug.