Closed Bug 359769 Opened 18 years ago Closed 17 years ago

[reflow branch] huge white space on the page

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: fullmetaljacket.xp+bugmail, Unassigned)

References

()

Details

(Keywords: qawanted, Whiteboard: [box/block])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a1) Gecko/20061106 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a1) Gecko/20061106 Minefield/3.0a1

huge white space on the heading of the forum thread.

this site is previously reported with this layout bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=354621

which is duplicate of this (-moz-inline-box):
https://bugzilla.mozilla.org/show_bug.cgi?id=321402

Reproducible: Always
Component: General → Location Bar and Autocomplete
OS: Windows XP → Windows Vista
Version: unspecified → Trunk
Component: Location Bar and Autocomplete → General
Product: Firefox → Core
QA Contact: general → general
Component: General → Layout
QA Contact: general → layout
Is this different on the reflow branch than it is on the trunk?  If it's also a trunk bug, it shouldn't be marked as [reflow branch].  And if it's a duplicate, it should be marked as a duplicate.
Yeah, this is different on branch.  It's just the same site as the other bug, but the actual problem is a different one -- with branch there's a huge blank space at the top of the page...

Also, I see lots of (order of a hundred or so):

###!!! ASSERTION: frame should be clean when getting special height reflow: '!mFlags.mSpecialHeightReflow || !(aFrame->GetStateBits() & (NS_FRAME_IS_DIRTY | NS_FRAME_HAS_DIRTY_CHILDREN))', file ../../../mozilla/layout/generic/nsHTMLReflowState.cpp, line 148

A minimal testcase would help a lot...
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
OS: Windows Vista → All
Hardware: PC → All
(In reply to comment #2)
> Also, I see lots of (order of a hundred or so):
> 
> ###!!! ASSERTION: frame should be clean when getting special height reflow:
> '!mFlags.mSpecialHeightReflow || !(aFrame->GetStateBits() & (NS_FRAME_IS_DIRTY
> | NS_FRAME_HAS_DIRTY_CHILDREN))', file
> ../../../mozilla/layout/generic/nsHTMLReflowState.cpp, line 148

I think I fixed those yesterday evening.
I do see:

...
nsBlockReflowContext: TableOuter(table)(1)@0x9c98c04 metrics=6255,1073742129!
nsBlockReflowContext: Block(div)(3)@0x9c989f8 metrics=6255,1073742129!
nsBlockReflowContext: Block(div)(5)@0x9c98454 metrics=6399,1073786121!
nsBlockReflowContext: Block(div)(3)@0x9c9770c metrics=6597,1073786976!
nsBlockReflowContext: TableOuter(table)(0)@0x9c97050 metrics=6669,1073787012!
nsBlockReflowContext: TableOuter(table)(1)@0x9c966a8 metrics=6687,1073787012!
nsBlockReflowContext: Block(div)(3)@0x9c96474 metrics=6687,1073787012!
nsBlockReflowContext: Block(div)(32)@0x9bbc60c metrics=6687,1073788524!
nsBlockReflowContext: Block(form)(1)@0x9b5bab8 metrics=6687,1073788524!
nsBlockReflowContext: Block(body)(1)@0x9b5b41c metrics=6687,1073788524!
...
I should be able to figure this out without a minimal testcase.  It looks like something in the block code is doing math on NS_UNCONSTRAINEDSIZE.
Which is coming from an nsBoxFrame for a span element, part of a line, whose nsLineLayout::PerFrameData::mBounds.y (0xbffffff7) doesn't match its mRect.y (0x1b).
Which is because an nsImageFrame reflowed within nsFrame::BoxReflow is given an mComputedHeight of 0x40000000.
Which is thanks to these lines in BoxReflow:

    // mComputedWidth and mComputedHeight are content-box, not
    // border-box
    reflowState.mComputedWidth = size.width;
    reflowState.mComputedHeight = size.height;

(gdb) p/x size
$6 = {width = 0x36, height = 0x40000000}
And thanks to nsHTMLReflowState::InitConstraints assuming null parentReflowState == root frame.
This page also renders a huge long page of 'white-space'.  Hopefully its the same issue as this bug?

http://wincustomize.com/Skins.aspx?LibID=1

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061206 Minefield/3.0a1 Firefox ID:2006120614

I found another example of this: http://blogs.msdn.com/correcteurorthographiqueoffice/archive/2006/06/05/617653.aspx

Not only that, but the text making up the comments at the bottom is very screwy as you scroll with the mouse wheel. Changing tabs or highlighting the offending text puts it back to normal, but it will screw up again if you scroll it out of view then back again.
Not sure, but on forums.mozillazine.org someone () also mentioned a site with an big block being displayed:

Forum link:
http://forums.mozillazine.org/viewtopic.php?p=2640435#2640435


The incorrectly displayed page: (used tinyurl, is a big link)
http://tinyurl.com/yc2kab
I tried to narrow down the offending nodes with the DOM Inspector, and then put each site through the W3C Validator. One thing I found in common for every page was that DIV tags which are involved in this bug (red flashing border in the DOM Inspector) aren't closed off (end tag for "div" omitted, but OMITTAG NO was specified).

I tried making a test case for this but it wouldn't work, so there has to be some CSS or really ugly nested layouts and hacks involved.
www.torncity.com homepage has simeler issue
(In reply to comment #13)
> I tried making a test case for this but it wouldn't work, so there has to be
> some CSS or really ugly nested layouts and hacks involved.

Bug 359769 is probably the same bug, it has a minimised testcase. So for now it's probably not that important to have a testcase for this.

Blocks: 363176
(In reply to comment #15)

> Bug 359769 is probably the same bug, it has a minimised testcase. So for now

You obviously meant to say bug 363176.
(In reply to comment #16)
> You obviously meant to say bug 363176.

Oops! Yes, thanks.

(In reply to comment #15)
> (In reply to comment #13)
> > I tried making a test case for this but it wouldn't work, so there has to be
> > some CSS or really ugly nested layouts and hacks involved.
> 
> Bug 363176 is probably the same bug, it has a minimised testcase. So for now
> it's probably not that important to have a testcase for this.
> 

it seems that the two bugs are the same. i tried to study the source code of the webpage i reported.

the forum rating STAR IMAGE that should appears on the top-left of the page and the dropdown "Sort Post" list on the top-right was enclosed on <span> tag.


If the background image (http://msforums.ph/Themes/default/images/Common/body-background-gradient.jpg) is blocked , the huge white space goes away.
(In reply to comment #19)
> If the background image
> (http://msforums.ph/Themes/default/images/Common/body-background-gradient.jpg)
> is blocked , the huge white space goes away.
> 

i been blocking that background image (using adblock+) eversince but still there is that huge space on the top of the forum.

hmmm... huge white space is gone when TOOLS->Options->Content->LOAD IMAGE AUTOMATICALLY is set to FALSE.

while this bug is not yet been fixed, i got a better workaround than blocking images (this workaround specific only for forums generated by community server 2.x software).

huge white space is gone by blocking "/utility/ratingcontrol.js" using adblock+. that script was the one responsible for generating the star rating image between the <span> </span> tag that caused the huge white space.

this also seems to "fixed" bug# 363674


So...  Please stop adding comments for a bit?  Comment 8 and comment 9 explain what's going on with this bug, but it's getting to be _very_ hard to find them.  In particular, comments 18 through 22 just make it harder to fix this bug, not easier.
Flags: blocking1.9?
Blocks: 363388
Blocks: 363674
(In reply to comment #23)
> So...  Please stop adding comments for a bit?  Comment 8 and comment 9 explain
> what's going on with this bug, but it's getting to be _very_ hard to find them.
>  In particular, comments 18 through 22 just make it harder to fix this bug, not
> easier.
> 
At the risk of raising your anger, I am commenting anyway.  I thought it might be helpful to point out that this might be related to the issue in bug 321402.  This is yet another bug that disappears if you change all instances of moz-inline-box to moz-inline-block in the stylesheet.

I'll be quiet now. 
The patch attached to bug 9458 makes this page render correctly.
(In reply to comment #26)
> Hrm, might this have been fixed by bug 366667?
> 

Probably.

I can no longer reproduce this bug, bug 363176, bug 363388 or bug 363674.
I see the huge white space with a 2007-01-22 build, but not anymore with a 2007-01-23 build, so my guess this was somehow fixed by the patch for bug 367332.
Flags: blocking1.9?
confirmed fixed 

broken in 20070122_1740_firefox-3.0a2pre.en-US.win32
fixed in 20070122_2012_firefox-3.0a2pre.en-US.win32

http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1169516400&maxdate=1169525519

(In reply to comment #30)
> Is http://www.wuestenschiff.de/phpbb/ a different problem ?

Yes, please file a new bug for that (with a testcase, if you can)
yes no more huge white space on:

http://msforums.ph/forums/1/5140/ShowThread.aspx
http://forums.thedailywtf.com/forums/12/showforum.aspx
http://communityserver.org/forums/thread/527064.aspx

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a2pre) Gecko/20070122
Minefield/3.0a2pre ID:2007012220 [cairo]
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
(In reply to comment #31)
> (In reply to comment #30)
> > Is http://www.wuestenschiff.de/phpbb/ a different problem ?
> 
> Yes, please file a new bug for that (with a testcase, if you can)
> 
-> Bug 368199
Does anyone else see the text actually lagging when you scroll down the URL specified for this bug? When I see the page and scroll down the text lags behind the scrolling and then jumps to where it actually should be when the scrolling stops.

Would that be related here or is that a new bug also? (Maybe not even related to reflow?)
Ignore my last comment, that's bug #368199.

Sorry for the bug spam everyone!
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.