Closed
Bug 359769
Opened 18 years ago
Closed 18 years ago
[reflow branch] huge white space on the page
Categories
(Core :: Layout, defect)
Core
Layout
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
Reporter | ||
Updated•18 years ago
|
Component: General → Location Bar and Autocomplete
OS: Windows XP → Windows Vista
Version: unspecified → Trunk
Reporter | ||
Updated•18 years ago
|
Component: Location Bar and Autocomplete → General
Updated•18 years ago
|
Product: Firefox → Core
QA Contact: general → general
Updated•18 years ago
|
Component: General → Layout
QA Contact: general → layout
Comment 1•18 years ago
|
||
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.
Comment 2•18 years ago
|
||
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
Comment 3•18 years ago
|
||
(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.
Comment 4•18 years ago
|
||
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! ...
Comment 5•18 years ago
|
||
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.
Comment 6•18 years ago
|
||
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).
Comment 7•18 years ago
|
||
Which is because an nsImageFrame reflowed within nsFrame::BoxReflow is given an mComputedHeight of 0x40000000.
Comment 8•18 years ago
|
||
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}
Comment 9•18 years ago
|
||
And thanks to nsHTMLReflowState::InitConstraints assuming null parentReflowState == root frame.
Updated•18 years ago
|
Whiteboard: [box/block]
Comment 10•18 years ago
|
||
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
Comment 11•18 years ago
|
||
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.
Comment 12•18 years ago
|
||
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
Updated•18 years ago
|
Blocks: reflow-refactor
Comment 13•18 years ago
|
||
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.
Comment 14•18 years ago
|
||
www.torncity.com homepage has simeler issue
Comment 15•18 years ago
|
||
(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.
Comment 16•18 years ago
|
||
(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.
Comment 17•18 years ago
|
||
(In reply to comment #16) > You obviously meant to say bug 363176. Oops! Yes, thanks.
Reporter | ||
Comment 18•18 years ago
|
||
(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.
Comment 19•18 years ago
|
||
If the background image (http://msforums.ph/Themes/default/images/Common/body-background-gradient.jpg) is blocked , the huge white space goes away.
Reporter | ||
Comment 20•18 years ago
|
||
(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.
Reporter | ||
Comment 21•18 years ago
|
||
hmmm... huge white space is gone when TOOLS->Options->Content->LOAD IMAGE AUTOMATICALLY is set to FALSE.
Reporter | ||
Comment 22•18 years ago
|
||
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
Comment 23•18 years ago
|
||
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?
Comment 24•18 years ago
|
||
(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.
Comment 25•18 years ago
|
||
The patch attached to bug 9458 makes this page render correctly.
Comment 26•18 years ago
|
||
Hrm, might this have been fixed by bug 366667?
Comment 27•18 years ago
|
||
(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.
Comment 28•18 years ago
|
||
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?
Comment 29•18 years ago
|
||
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
Comment 30•18 years ago
|
||
Is http://www.wuestenschiff.de/phpbb/ a different problem ?
Comment 31•18 years ago
|
||
(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)
Reporter | ||
Comment 32•18 years ago
|
||
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]
Reporter | ||
Updated•18 years ago
|
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment 33•18 years ago
|
||
(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
Comment 34•18 years ago
|
||
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?)
Comment 35•18 years ago
|
||
Ignore my last comment, that's bug #368199. Sorry for the bug spam everyone!
Updated•18 years ago
|
Flags: in-testsuite?
You need to log in
before you can comment on or make changes to this bug.
Description
•