The URL given lays out incorrectly, with the area which should contain the news articles blank and the content pushed down into the next available area for layout. Mozilla also gives this warning as it loads the page: BUG - table cell content max element height greater than desired height This problem is seen both on a Linux/sparc build from a 3/3 evening CVS pull and the mozilla.org 3/3 nightly binary for Win32.

Chris P, can you see if this a problem on an optimized build. It looks ok on my 3/23 WinNT debug build. The warning message reported is not a major concern.

Fixed in April 5th Build.

It appears that the news.com homepage has changed so that it doesn't exhibit this problem anymore. Here's an article which shows the problem and hopefully will be more stable: http://www.news.com/News/Item/0,4,34636,00.html The text of the article gets placed below the right hand sidebar (4/5 win32 nightly binary):

petersen, is this Linux/Unix specific?

Moving to M6.

Moving to M8.

[using may23 win95 opt] Going to the article URL listed above, and www.news.com, I no longer see the behaviour (but I did see it, as described, in April). (There were some other flow-related bugs that were fixed a couple of weeks ago, I believe). There are a variety of small bugs on the page but they are all known/reported (e.g., 'residual font', 'inline/block', '/form & tables', etc.) but if you weren't comparing directly to 4.5 (win), you wouldn't really notice them. I would recommend closing this one. (comments tor@cs.brown.edu? )

I don't see this problem in the Latest build (June 29th). Works for me.

Moving to M9.

How the browser draws the page to make full use of the page's space needs to be improved

Please reread http://www.mozilla.org/newlayout/bugathon.html for a general description of that the engineers are looking for in a testcase. They want a small snippet of HTML that will reproduce the problem, not instructions directing them to visit a major site. The bug-a-thon was created so that people outside of netscape would take the time needed to distill a large page down to the minimum needed to show the problem, and thus save the mozilla/netscape engineers this effort.

I'm clearing the status whiteboard, since there still isn't a smaller test case.

I don't see the reported problem on the page mentioned in the 4/6 comments. Marking fixed.

Based on the original description, the problem is no nolonger occuring. The page was tested with the Sept 2 build.