Closed Bug 169620 Opened 22 years ago Closed 22 years ago

cnn.com news scrolls off the page; paragraphs do not wrap

Categories

(Core :: Layout, defect, P1)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.2beta

People

(Reporter: P, Assigned: karnaze)

References

(
URL
)

Details

(Keywords: regression, top100, topembed, Whiteboard: [adt2] [ETA Needed])

Attachments

(4 files)

Screenshot of cnn article.
82.71 KB, image/png
Details
testcase using the gettysburg address for long lines
1.74 KB, text/html
Details
patch to fix evil DEBUG-only code that hides this bug in DEBUG builds
1.47 KB, patch
bernd_mozilla
: review+
Details | Diff | Splinter Review
patch to fix the bug (including the evil debug code plus more)
8.16 KB, patch
dbaron
: review+
kinmoz
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020915 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020915 All Paragraphs in news stories on cnn.com no not wrap but scroll far off to the right. Reproducible: Always Steps to Reproduce: 1. Load any cnn.com story. 2. Paragraphs do not wrap. Actual Results: No paragraphs wrap, story scrolls far off to the right. Expected Results: You should be able to read the story without scrolling to the right. Looks proper in IE 5.5 and Opera 6.
Looks fine in Netscape 7 also. Turning off CSS with a bookmarklet I have fixes it. The only stylesheet on the page is: http://www.cnn.com/.element/ssi/css/1.0/main.css But I don't see anything in it that might be the cause. The HTML is certainly not valid though.
Works for me on Gecko/20020823 commercial branch Win2K upon first time accessing the page. Can you still replicate? If so I will flip this to a browser bug.
WFM in Netscape 7.0RTM WFM in Mozilla 1.2a, build 2002091014, both on Win2K
Confirming bug with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20020919
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirming the bug in Build 2002091014, WinNT 4.0 SP6
WFM on Win2K with Gecko/20020917 commercial branch Confirming the bug in Win2K with 1.2 alpha Build 2002091014 mozilla trunk AFTER reloading. Initially page laid out correctly. Marking as a layout regression
Assignee: susiew → attinasi
Component: US General → Layout
Keywords: nsbeta1, top100, topembed
Priority: -- → P1
Product: Tech Evangelism → Browser
QA Contact: zach → petersen
Summary: cnn.com news stories scroll far off the page; paragraphs do not wrap → cnn.com news scrolls off the page; paragraphs do not wrap
Version: unspecified → other
Keywords: regression
Kevin, please assign. Thanks.
This is a bug in the renderer of some sort. The test case is as simple as I can get it but it is still fairly complex. To demonstrate this bug you need: * Fairly long lines * A div nested inside a table that contains those lines. * An <hr> tag inside the div * A second cell on that table (table must be at least two cells wide) * Padding on the right of the div * A JavaScript in the table that references "document" * A Second JavaScript in the table loaded from an external page (could be empty on non-existent) Remove any one of these elements and the text wraps properly.
Dupe of bug 169568? Or the other way around?
No wrap in 2002091908 linux. This is actually more than just not wrapping. It's much wider then it would be in just <nobr>'s. Most of the horizontal space is blank.
-> Karnaze
Assignee: attinasi → karnaze
*** Bug 169793 has been marked as a duplicate of this bug. ***
I am seeing this problem, both on cnn.com and with the attached test case, on a Windows 20020918 build. Changing the text zoom (and optionally changing it back to 100%) causes the page to render correctly.
*** Bug 169568 has been marked as a duplicate of this bug. ***
bug 169568 has another good testcase.
*** Bug 169813 has been marked as a duplicate of this bug. ***
In bug 169568 comment 13, Andrew mentions the fix for bug 154780 as a possible culprit?
Edit page renders the cnn and testcase correctly, most of the time, but the browser has this bug. 2002091608 MacOS9.x trunk.
I download yesterday's trunk tarball , build it on sparc, it works fine, both testcase and url. if it is a reflow bug, it should be the same on different platforms, but now I am surprised.
The bug is not 100% reproducible in my case either. I have been on the same connection and Mozilla has been up running since my last post (comment #20), but the testcase and the cnn render correctly now.
*** Bug 169857 has been marked as a duplicate of this bug. ***
I see this bug on CNN 100% of the time. It appears to layout correctly, but then gets munged and goes wide after a reflow. The weird part for me is this 100% effective workaround: I can workaround this problem by causing a reload while holding the shift key. The shift key must be held through the reflow for this to work. If I initiate the reload with shift, and then release the shift before the reflow, the reflow breaks the layout as reported.
I'm seeing exactly the same as Stephen. Shift+reload only works if you keep the shift key pressed until the final layout. Bizarre !!!!! 2002091904 NT4
I checked it with Mozilla 1.0.1 Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20020913 and everything looks ok.
I'm seeing the same as Stephen in comment 24 also. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910 This is kinda weird -- especially the "shift"-key thing. Maybe the NS bar on the top needs a note saying "only read our stories after hitting shift-reload if you're using Gecko? Uhhhh ... maybe not.
The testcase from the other bug is almost identical to the one I supplied here. It doesn't have long lines of text, proving long lines are not required for the bug. It does use a "document.write(...);" which can be shortened to just "document;" and still produce the bug. I congratulate Andrew Schultz on creating that testcase. It took me over an hour to pare away CNN's html, include their external documents, then whittle the css and javascript down. I wish I had seen that he had done it before I went ahead and did it.
Also, since this bug depends on javascript, another work around is disable javascript.
*** Bug 169911 has been marked as a duplicate of this bug. ***
Have this problem with WinXP. One question, someone mentioned that turning off the CSS fix the problem. I don't see that feature in the Preference setting from Mozilla. Can anyone tell me where it can be found? The shift-reload does not fix the problem in my case as someone claimed.
shift+reload doesn't work for me either on Linux 20020918. I also don't get an extra reflow as described in comment #24. I get the borked page on the first reflow.
My shift-reload and relfow observations were based on WinXP Pro. I'm also confident that other observations like this are all Win32 based.
Well, mine is WinXP Professional. Still, it doesn't work with shift-reload and reflow. Look like I'm going to have to start using IE for reading the cnn.com articles. I'm going to vote for this bug.
*** Bug 170005 has been marked as a duplicate of this bug. ***
I can't reproduce the problem on my current win2k debug build.
> I can't reproduce the problem on my current win2k debug build. debug build worksforme on linux as well. however, it does complain: Block(div)(5)@0x884c794: Init: bad caller: width WAS 1073741624(0x3fffff38) which appears relevant to this bug
I also see this behaviour with Mozilla 1.2a running on Windows XP Professional SP1. I was able to work around with the shift-reload and holding the shift button down. Strange stuff.
This patch fixes some extremely evil DEBUG-only code that prevents this bug from being visible in DEBUG builds. DEBUG code should be testing things, but it shouldn't be changing them, since that makes bugs unreproducable in DEBUG builds.
My testing of nightly builds shows that this started between 2002-09-04-04 and 2002-09-12-09. Other comments in this bug show it was before 2002-09-10-14. Does anyone still have nightly builds from that period to reduce it further?
from bug 169568 comment 5 > trunk build 2002090905 works, trunk build 2002091016 (1.2a) does not bug 154780 fits in that window and is consistent with the behavior here
Confirmed. Backing out bug 154780 in my tree using the commands: cvs up -j3.100 -j3.99 nsTableRowFrame.h cvs up -j3.314 -j3.313 nsTableRowFrame.cpp fixes this bug.
*** Bug 170093 has been marked as a duplicate of this bug. ***
Comment on attachment 100100 [details] [diff] [review] patch to fix evil DEBUG-only code that hides this bug in DEBUG builds r=bernd
Attachment #100100 - Flags: review+
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2beta
I think the patch in bug 154780 only exposed problems in the block/inline code (e.g. supplying negative values for available widths and performing arithmetic on unconstrained values). This patch also contains what's in the previous patch plus another case of the same.
Comment on attachment 100129 [details] [diff] [review] patch to fix the bug (including the evil debug code plus more) So what exactly is being passed into the block code that's unconstrained that never was before? >Index: html/base/src/nsBlockReflowState.cpp >- mContentArea.width = aReflowState.availableWidth - lr; >+ mContentArea.width = PR_MAX(0, aReflowState.availableWidth - lr); >- mContentArea.height = mBottomEdge - borderPadding.top; >+ mContentArea.height = PR_MAX(0, mBottomEdge - borderPadding.top); Does something bad happen if these go below zero? (It makes sense, although I'm wondering if there are obscure cases that it could break.) >Index: html/base/src/nsHRFrame.cpp > // When the HR is using an 'auto' or percentage width, make sure it > // remains springy. > aDesiredSize.maxElementSize->width = onePixel; >+ aDesiredSize.width = PR_MAX(aDesiredSize.width, onePixel); > aDesiredSize.maxElementSize->width = onePixel; >+ aDesiredSize.width = PR_MAX(aDesiredSize.width, onePixel); Perhaps we should instead have a better way of saying that the maxElementSize->width is zero, instead of changing the width? Can we just say it's zero? Or unconstrained? >Index: html/base/src/nsInlineFrame.cpp > availableWidth -= aReflowState.mComputedBorderPadding.right; >+ availableWidth = PR_MAX(0, availableWidth); See comment above on nsBlockReflowState.cpp. >Index: html/base/src/nsLineLayout.cpp > // Advance to next X coordinate > psd->mX = pfd->mBounds.XMost() + pfd->mMargin.right; >+ psd->mRightEdge = PR_MAX(psd->mRightEdge, psd->mX); Same comment as on BlockReflowState.cpp (except that it's not "below zero").
>So what exactly is being passed into the block code that's unconstrained >that never was before? As far as I can tell, nothing. The block appears to be given an avail width of 0 and then reflowing frames internally with an unconstrained width, which causes some arithmetic on NS_UNCONSTRAINEDSIZE when constructing the reflow state. See the dump below. >Does something bad happen if these go below zero? (It makes sense, although >I'm wondering if there are obscure cases that it could break.) I'm not sure what the advantages are for allowing negative avail widths. When I removed the code which ensures they are >= 0, I hit assertions where things wanted to have negative desired widths (does that also make sense?), but it didn't cause any problems on the test case. Should I develop another patch with this stuff removed and see if it breaks any regression tests or is there some reason to allow negative avail widths? I'm afraid that by allowing things to return negative desired widths we will run into problems even if the regression tests don't catch it. If we allow negative avail widths but not negative desired widths, then that could be a big job involving a lot of frame classes. >Perhaps we should instead have a better way of saying that the >maxElementSize->width is zero, instead of changing the width? >Can we just say it's zero? Or unconstrained? I'm not sure, but I'll open another bug on this. It looks like someone ran into problems when the HR's MES was set to 0. If it needs to be set > 0, then it makes sense to set the desired width to match, otherwise it might cause problems for callers (I think the table code is working around this problem). I'm not sure what would be gained by making it unconstrained. ----------- tbl 037B1170 r=0 a=13350,UC c=UC,UC cnt=1932 rowG 037B1328 r=0 a=UC,UC c=UC,UC cnt=1933 row 037B14B4 r=0 a=UC,UC c=UC,UC cnt=1934 cell 037B1628 r=0 a=UC,UC c=UC,UC cnt=1935 block 037B1688 r=0 a=UC,UC c=UC,UC cnt=1936 text 037BB05C r=0 a=UC,UC c=UC,UC cnt=1937 text 037BB05C d=0,0 me=0 block 037B1688 d=0,0 me=0 .... tbl 037B1170 r=1 a=13350,UC c=UC,UC cnt=1975 rowG 037B1328 r=1 a=90,UC c=90,UC cnt=1976 row 037B14B4 r=1 a=90,UC c=90,UC cnt=1977 cell 036C2380 r=0 a=UC,UC c=UC,UC cnt=1978 block 036C23E0 r=0 a=UC,UC c=UC,UC cnt=1979 text 036C2430 r=0 a=UC,UC c=UC,UC cnt=1980 text 036C2430 d=0,0 me=0 block 036C23E0 d=0,0 me=0 cell 036C2380 d=30,60 me=30 cell 037B1628 r=1 a=30,UC c=UC,UC cnt=1981 block 037B1688 r=1 a=0,UC c=UC,UC cnt=1982 text 037BB05C r=2 a=UC,UC c=UC,UC cnt=1983 text 037BB05C d=0,0 me=0 text 037BB828 r=2 a=UC,UC c=UC,UC cnt=1984 text 037BB828 d=0,0 me=0 text 037BB8AC r=0 a=UC,UC c=UC,UC cnt=1985 text 037BB8AC d=0,0 me=0 text 037BB05C r=2 a=0,UC c=UC,UC cnt=1986 text 037BB05C d=0,0 text 037BB828 r=2 a=0,UC c=UC,UC cnt=1987 text 037BB828 d=0,0 text 037BB8AC r=2 a=0,UC c=UC,UC cnt=1988 text 037BB8AC d=0,0 block 037BBA00 r=0 a=UC,UC c=UC,UC cnt=1989 text 037BBA84 r=0 a=UC,UC c=UC,UC cnt=1990 text 037BBA84 d=0,0 me=0 text 037BBA84 r=2 a=UC,UC c=UC,UC cnt=1991 text 037BBA84 d=0,0 block 037BBBE8 r=0 a=UC,UC c=UC,UC cnt=1992 text 037BBAF4 r=0 a=UC,UC c=UC,UC cnt=1993 text 037BBAF4 d=15780,285 me=1020 text 037BBAF4 r=2 a=UC,UC c=UC,UC cnt=1994 text 037BBAF4 d=15780,285 block 037BBBE8 d=15780,300 me=1020 m=15780 block 037BBBE8 r=2 a=UC,UC c=UC,UC cnt=1995 text 037BBAF4 r=2 a=UC,UC c=UC,UC cnt=1996 text 037BBAF4 d=15780,285 me=1020 text 037BBAF4 r=2 a=UC,UC c=UC,UC cnt=1997 text 037BBAF4 d=15780,285 block 037BBBE8 d=15780,300 me=1020 m=15780 text 037BBC98 r=0 a=UC,UC c=UC,UC cnt=1998 text 037BBC98 d=0,0 me=0 text 037BBC98 r=2 a=UC,UC c=UC,UC cnt=1999 text 037BBC98 d=0,0 block 037BBCDC r=0 a=UC,UC c=UC,UC cnt=2000 text 037BBD2C r=0 a=UC,UC c=UC,UC cnt=2001 text 037BBD2C d=16380,285 me=945 text 037BBD2C r=2 a=UC,UC c=UC,UC cnt=2002 text 037BBD2C d=16380,285 block 037BBCDC d=16380,300 me=945 m=16380 block 037BBCDC r=2 a=UC,UC c=UC,UC cnt=2003 text 037BBD2C r=2 a=UC,UC c=UC,UC cnt=2004 text 037BBD2C d=16380,285 me=945 text 037BBD2C r=2 a=UC,UC c=UC,UC cnt=2005 text 037BBD2C d=16380,285 block 037BBCDC d=16380,300 me=945 m=16380 text 037BBD9C r=0 a=UC,UC c=UC,UC cnt=2006 text 037BBD9C d=0,0 me=0 text 037BBD9C r=2 a=UC,UC c=UC,UC cnt=2007 text 037BBD9C d=0,0 block 037BBDE0 r=0 a=UC,UC c=UC,UC cnt=2008 text 037BBE30 r=0 a=UC,UC c=UC,UC cnt=2009 text 037BBE30 d=16890,285 me=885 text 037BBE30 r=2 a=UC,UC c=UC,UC cnt=2010 text 037BBE30 d=16890,285 block 037BBDE0 d=16890,300 me=885 m=16890 block 037BBDE0 r=2 a=UC,UC c=UC,UC cnt=2011 text 037BBE30 r=2 a=UC,UC c=UC,UC cnt=2012 text 037BBE30 d=16890,285 me=885 text 037BBE30 r=2 a=UC,UC c=UC,UC cnt=2013 text 037BBE30 d=16890,285 block 037BBDE0 d=16890,300 me=885 m=16890 text 037BBEA0 r=0 a=UC,UC c=UC,UC cnt=2014 text 037BBEA0 d=0,0 me=0 text 037BBEA0 r=2 a=UC,UC c=UC,UC cnt=2015 text 037BBEA0 d=0,0 block 037BBEE4 r=0 a=UC,UC c=UC,UC cnt=2016 text 037BBF34 r=0 a=UC,UC c=UC,UC cnt=2017 text 037BBF34 d=29310,285 me=1095 text 037BBF34 r=2 a=UC,UC c=UC,UC cnt=2018 text 037BBF34 d=29310,285 block 037BBEE4 d=29310,300 me=1095 m=29310 block 037BBEE4 r=2 a=UC,UC c=UC,UC cnt=2019 text 037BBF34 r=2 a=UC,UC c=UC,UC cnt=2020 text 037BBF34 d=29310,285 me=1095 text 037BBF34 r=2 a=UC,UC c=UC,UC cnt=2021 text 037BBF34 d=29310,285 block 037BBEE4 d=29310,300 me=1095 m=29310 text 037BBFA4 r=0 a=UC,UC c=UC,UC cnt=2022 text 037BBFA4 d=0,0 me=0 text 037BBFA4 r=2 a=UC,UC c=UC,UC cnt=2023 text 037BBFA4 d=0,0 block 036C1AC8 r=0 a=UC,UC c=UC,UC cnt=2024 text 036C1B18 r=0 a=UC,UC c=UC,UC cnt=2025 text 036C1B18 d=52140,285 me=1050 text 036C1B18 r=2 a=UC,UC c=UC,UC cnt=2026 text 036C1B18 d=52140,285 block 036C1AC8 d=52140,300 me=1050 m=52140 block 036C1AC8 r=2 a=UC,UC c=UC,UC cnt=2027 text 036C1B18 r=2 a=UC,UC c=UC,UC cnt=2028 text 036C1B18 d=52140,285 me=1050 text 036C1B18 r=2 a=UC,UC c=UC,UC cnt=2029 text 036C1B18 d=52140,285 block 036C1AC8 d=52140,300 me=1050 m=52140 text 036C1B88 r=0 a=UC,UC c=UC,UC cnt=2030 text 036C1B88 d=0,0 me=0 inline 036C1E40 r=0 a=UC,UC c=UC,UC cnt=2031 inline 036C1EAC r=0 a=UC,UC c=UC,UC cnt=2032 text 036C1F18 r=0 a=UC,UC c=UC,UC cnt=2033 text 036C1F18 d=0,285 me=0 inline 036C1EAC d=0,285 me=0 inline 036C1E40 d=0,285 me=0 status=17153 text 036C1B88 r=2 a=UC,UC c=UC,UC cnt=2034 text 036C1B88 d=0,0 inline 036C1E40 r=2 a=UC,UC c=UC,UC nif=036C2704 cnt=2035 inline 036C1EAC r=2 a=UC,UC c=UC,UC cnt=2036 text 036C1F18 r=2 a=UC,UC c=UC,UC cnt=2037 text 036C1F18 d=0,285 inline 036C1EAC d=0,285 inline 036C1E40 d=0,0 status=17153 inline 036C2704 r=0 a=UC,UC c=UC,UC pif=036C1E40 cnt=2038 hr 036C1D00 r=0 a=UC,UC c=UC,UC cnt=2039 hr 036C1D00 d=15,315 me=15 inline 036C200C r=0 a=UC,UC c=UC,UC cnt=2040 text 036C2078 r=0 a=UC,UC c=UC,UC cnt=2041 text 036C2078 d=0,285 me=0 inline 036C200C d=0,285 me=0 inline 036C2704 d=15,285 me=15 text 036C20BC r=0 a=UC,UC c=UC,UC cnt=2042 text 036C20BC d=0,0 me=0 text 036C20BC r=2 a=UC,UC c=UC,UC cnt=2043 text 036C20BC d=0,0 block 037BBA00 d=52290,3015 me=1245 m=52290 block 037BBA00 r=2 a=0,UC c=UC,UC cnt=2044 text 037BBA84 r=2 a=UC,UC c=UC,UC cnt=2045 text 037BBA84 d=0,0 me=0 Block(div)(5)@037BBA00: Init: bad caller: width WAS 1073741674(0x3fffff6a) text 037BBA84 r=2 a=1073741674,UC c=UC,UC cnt=2046 text 037BBA84 d=0,0 block 037BBBE8 r=2 a=1073741674,UC c=UC,UC cnt=2047
>> psd->mX = pfd->mBounds.XMost() + pfd->mMargin.right; >>+ psd->mRightEdge = PR_MAX(psd->mRightEdge, psd->mX); >Same comment as on BlockReflowState.cpp (except that it's not "below zero"). In this case, I seem to recall that someone does (psd->mRightEdge - psd->mX) to get a negative avail width, so the previous comments of negative avail widths apply.
Comment on attachment 100129 [details] [diff] [review] patch to fix the bug (including the evil debug code plus more) I'd be willing (although not enthusiastic) to mark r=dbaron for the trunk. However, I'm not convinced that this is safe for the branch. Without understanding why this started happening, I don't see how we can tell that all the regressions are fixed.
*** Bug 170197 has been marked as a duplicate of this bug. ***
I think the following piece from the patch in bug 154780 explains why this started happening. Before bug 154780, the cell probably reflowed its block with an availWidth = 0 and a computedWidth = 0 (since it had balanced and the col width == 0). After bug 154780 it reflowed with an availWidth = 0 and a computedWidth = unconstrained. That combination caused problems. + // If the table will intialize the strategy (and balance) or balance, make the computed + // width unconstrained. This avoids having the cell block compute a bogus max width + // which will bias the balancing. Leave the avail width alone, since it is a best guess. + // After the table balances, the cell will get reflowed with the correct computed width.
While this is getting fixed, I've just found a somewhat bizarre workaround for Linux, which works on 2002092010trunk Just open the link in a new window (a new tab, in my case. I haven't tested new window), using the middle mouse button and wait for it to finish loading. Now, close the new tab and reopen, using middle mouse click again. The second time, the page should load correctly. This does not appear to work using left click-back button-left click.
So does this fix (and the proposed reason it appeared) take into account why on a reload with shift, changing the text size, or a new tab makes it appear ok? Just curious.
The bug probably does not appear in situations described in the previous comment because the reflow command sequence is different. Based on the dump in comment #47, it takes a situation where a cell gets reflowed and has no width, then gets an incremental reflow and gets a lot of width. It may also require that the coalesced reflow command contains a dirty reflow targeted at the row which causes a new cell to be reflowed for the 1st time (as the dump indicates).
This is a visible regresison that is effecting a topsite, so nsbeta1+.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2] [ETA Needed]
This is info of minimal use; I just went to a lot of trouble extracting the troublesome parts of one of the bad cnn pages BEFORE I searched for this bug, so I have to put my findings somewhere. This page causes the problem, but if /any/ of the lines marked XXX are removed, it lays out fine. The fourth patch ("patch to fix the bug") does fix this page. <html><body> <table> <tr> <td> <div style="padding-right: 10px"> <!-- XXX --> <script> document.write('anything'); <!-- XXX --> </script> <script src="nosuchscript.js"></script> <!-- XXX --> <hr style="width: 464px;"> <!-- XXX --> </div> </td> <td width="160"></td> <!-- XXX --> </tr> </table> </body></html>
A third person has deconstructed cnn html,js,css hell! (congratulations, danm ;-) In danm's example: You can change "document.write('anything');" to "document;" You can remove the widths from the hr and td.
QA Contact: petersen → amar
*** Bug 170468 has been marked as a duplicate of this bug. ***
*** Bug 170524 has been marked as a duplicate of this bug. ***
Comment on attachment 100129 [details] [diff] [review] patch to fix the bug (including the evil debug code plus more) r=dbaron
Attachment #100129 - Flags: review+
Comment on attachment 100129 [details] [diff] [review] patch to fix the bug (including the evil debug code plus more) sr=kin@netscape.com ==== To be consistent with the rest of layout should we use NS_UNCONSTRAINEDSIZE instead of NS_MAXSIZE? + aRect.width = PR_MAX(mTopRightX, mBottomRightX); + if (NS_MAXSIZE != aRect.width) { + aRect.width -= aRect.x; + } + aRect.height = (NS_MAXSIZE == mBottomY) ? NS_MAXSIZE : mBottomY - mTopY;
Attachment #100129 - Flags: superreview+
NS_UNCONSTRAINEDSIZE is defined in layout/html/base/src/nsHTMLReflowState.h and isn't included by layout/base/src/nsSpaceManager.h
*** Bug 170577 has been marked as a duplicate of this bug. ***
*** Bug 170521 has been marked as a duplicate of this bug. ***
The patch is in the trunk. It is not needed in the branch, because bug 154780 wasn't checked into the branch.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 170601 has been marked as a duplicate of this bug. ***
*** Bug 170715 has been marked as a duplicate of this bug. ***
*** Bug 170691 has been marked as a duplicate of this bug. ***
*** Bug 170726 has been marked as a duplicate of this bug. ***
*** Bug 170742 has been marked as a duplicate of this bug. ***
*** Bug 170780 has been marked as a duplicate of this bug. ***
*** Bug 170771 has been marked as a duplicate of this bug. ***
*** Bug 170807 has been marked as a duplicate of this bug. ***
*** Bug 170756 has been marked as a duplicate of this bug. ***
*** Bug 170868 has been marked as a duplicate of this bug. ***
*** Bug 170954 has been marked as a duplicate of this bug. ***
*** Bug 170958 has been marked as a duplicate of this bug. ***
*** Bug 171008 has been marked as a duplicate of this bug. ***
*** Bug 171099 has been marked as a duplicate of this bug. ***
*** Bug 171112 has been marked as a duplicate of this bug. ***
removing my name since it is fixed. Receiving too many emails
*** Bug 170958 has been marked as a duplicate of this bug. ***
*** Bug 171293 has been marked as a duplicate of this bug. ***
Removing my name... sorry for the duplicate.
unsubscribe
*** Bug 171477 has been marked as a duplicate of this bug. ***
*** Bug 171306 has been marked as a duplicate of this bug. ***
v linux and windows.
*** Bug 171603 has been marked as a duplicate of this bug. ***
*** Bug 171642 has been marked as a duplicate of this bug. ***
*** Bug 171668 has been marked as a duplicate of this bug. ***
*** Bug 171712 has been marked as a duplicate of this bug. ***
*** Bug 171746 has been marked as a duplicate of this bug. ***
*** Bug 171839 has been marked as a duplicate of this bug. ***
*** Bug 171843 has been marked as a duplicate of this bug. ***
*** Bug 171923 has been marked as a duplicate of this bug. ***
*** Bug 171940 has been marked as a duplicate of this bug. ***
*** Bug 171945 has been marked as a duplicate of this bug. ***
*** Bug 171993 has been marked as a duplicate of this bug. ***
*** Bug 172160 has been marked as a duplicate of this bug. ***
*** Bug 172271 has been marked as a duplicate of this bug. ***
*** Bug 172321 has been marked as a duplicate of this bug. ***
*** Bug 172350 has been marked as a duplicate of this bug. ***
Verified.
Status: RESOLVED → VERIFIED
*** Bug 172456 has been marked as a duplicate of this bug. ***
*** Bug 172481 has been marked as a duplicate of this bug. ***
*** Bug 172602 has been marked as a duplicate of this bug. ***
*** Bug 172630 has been marked as a duplicate of this bug. ***
*** Bug 172742 has been marked as a duplicate of this bug. ***
*** Bug 172836 has been marked as a duplicate of this bug. ***
*** Bug 172905 has been marked as a duplicate of this bug. ***
*** Bug 172938 has been marked as a duplicate of this bug. ***
*** Bug 172940 has been marked as a duplicate of this bug. ***
*** Bug 172977 has been marked as a duplicate of this bug. ***
*** Bug 173071 has been marked as a duplicate of this bug. ***
*** Bug 173109 has been marked as a duplicate of this bug. ***
*** Bug 173300 has been marked as a duplicate of this bug. ***
*** Bug 173409 has been marked as a duplicate of this bug. ***
*** Bug 173483 has been marked as a duplicate of this bug. ***
*** Bug 173637 has been marked as a duplicate of this bug. ***
*** Bug 173718 has been marked as a duplicate of this bug. ***
*** Bug 173720 has been marked as a duplicate of this bug. ***
*** Bug 173840 has been marked as a duplicate of this bug. ***
*** Bug 173842 has been marked as a duplicate of this bug. ***
It is still occurring, still after patch.
it is still occurring, after new patch.
It is still occurring, after new patch.
Bug is still occurring, after patch.
I'm not seeing a problem with the previous url on a 10/10/2 debug build. If there is a problem with an optimized build, please file a new bug, since this is a different url.
Renee, what build of Mozilla are you using? I just tried the link you gave with build 2002101108, Win98, and it works for me.
Still not fixed, as of today 10/12/02/
Still not fixed, as of 10/12/02.
Still not fixed, as of 10/12/02.
Still not fixed, as of 10/12/02.
Still not fixed, as of 10/12/02.
*** Bug 174124 has been marked as a duplicate of this bug. ***
*** Bug 174181 has been marked as a duplicate of this bug. ***
*** Bug 174183 has been marked as a duplicate of this bug. ***
*** Bug 174260 has been marked as a duplicate of this bug. ***
Renee, can you please post your build ID? You can find the build ID in Mozilla by choosing the Help->About Mozilla menu. You should see text that looks something like "Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20021011". The last part "rv:1.2b) Gecko/20021011" is what you need to report. There is no way for the rest of us to guess what version you are running.
*** Bug 174292 has been marked as a duplicate of this bug. ***
*** Bug 174338 has been marked as a duplicate of this bug. ***
I am in build Mozilla build 1.2A, and it is still happening in that build.
*** Bug 174346 has been marked as a duplicate of this bug. ***
*** Bug 174358 has been marked as a duplicate of this bug. ***
Posting Renee's build info that I received in email: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2a) Gecko/20020910 Renee, you really need to get a newer version of Mozilla. This problem was fixed near the end of September.
74 duplicates and counting! Party in my cube when it hits 100.
*** Bug 174426 has been marked as a duplicate of this bug. ***
*** Bug 174501 has been marked as a duplicate of this bug. ***
Regarding Warner's comment to Renee: It appears that Renee is using the most recently posted binary build for Windows, released September 11. Given the large audience for these builds, and the potential help (as opposed to hindrance) that this audience (myself included) may provide to Mozilla QA efforts, may I suggest more frequent updates of the binaries?
http://www.cnn.com/2002/US/South/10/15/sniper.shootings/index.html Build: Mozilla 1.2a Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2a) Gecko/20020910 If there is a later version, I am unaware that it exists.....and as you can see, it is still occurring.
Renee, maybe I don't understand what you're saying, but how exactly could your browser get fixed without you downloading a new version? 1.2a was broken originally, and the nightly builds (and eventually 1.2b) are fixed. Why do you expect your browser to repair itself?
Renee, the binary releases are released only periodically. The reason that this is marked as 'FIXED', is because it has been fixed in the nightly builds. So, to see the fix, you can either download a nightly, or wait for 1.2beta, which will probably be out soon. If you'd like to always have the latest build, follow the 'Building Mozilla on Microsoft Windows 32-bit Platforms' here: http://www.mozilla.org/build/win32.html
"1.2a was broken originally, and the nightly builds (and eventually 1.2b) are fixed. Why do you expect your browser to repair itself?" That's not such a useful thing to say. When you go to mozilla.org and click on the "download" link in the sidebar, 1.2a is the only obvious version. Saying "go to the QA menu in Mozilla and look for the latest build" is more helpful.
I wasn't so much recommending a nightly build (I've gotten in trouble more than once d/ling one, only to find more bugs than were fixed). I just didn't understand the seemingly irritated tone the comments seemed to have. Renee emailed me, and he does now have a nightly, so problem solved.
*** Bug 174582 has been marked as a duplicate of this bug. ***
*** Bug 174747 has been marked as a duplicate of this bug. ***
*** Bug 174869 has been marked as a duplicate of this bug. ***
*** Bug 174907 has been marked as a duplicate of this bug. ***
I tried to download nightly build (mozilla-win32-talkback.zip) on 15/10/2002 to verify that this bug is fixed. What should I do about the files? Just replace the current installation? Or I have to build them again? I replaced the 1.2a installation, and starting mozilla only show the splash screen. That's it. Is that normal? (for nightly build, I mean).
What platform are you on? On Mac OS X and Windows 2000, I just downloaded the new binary/installer/thing. No recompilation.
*** Bug 175149 has been marked as a duplicate of this bug. ***
Finally got rid of this bug by downloading 1.2 Beta. Thanks team!
*** Bug 175545 has been marked as a duplicate of this bug. ***
*** Bug 175781 has been marked as a duplicate of this bug. ***
*** Bug 175986 has been marked as a duplicate of this bug. ***
*** Bug 176264 has been marked as a duplicate of this bug. ***
*** Bug 176343 has been marked as a duplicate of this bug. ***
*** Bug 176869 has been marked as a duplicate of this bug. ***
*** Bug 177131 has been marked as a duplicate of this bug. ***
*** Bug 177289 has been marked as a duplicate of this bug. ***
*** Bug 178731 has been marked as a duplicate of this bug. ***
*** Bug 179729 has been marked as a duplicate of this bug. ***
Alias: CNN
Blocks: 199819
No longer blocks: 199819
Blocks: 66522
No longer blocks: 66522
Blocks: 234019
No longer blocks: 234019
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: