Blake Ross, in his answer to <a href="http://bugzilla.mozilla.org/show_bug.cgi? id=42728">42728</a>, says "page parses/lays out completely incorrectly . . . Open a new bug for this problem and assign to layout or parser...resolving as wfm" I wasn't sure who the last line was directed at, but since no new bug with the same URL has appeared in the last fews days, I'm entering this one. I also took the liberty of whacking my looping M16 with a utility that forces a breakpoint exception, inducing Mozilla to send a Full Circle report.

with a P3 500 on Linux, 2000-061820 hangs before rendering anything of this page, 99% CPU "forever". Killed it after 3 minutes, was jammed.

page now lays out fine for me on 61920 win98...

Encouraged by Mr. Ross' report that it worked in Win98 with a more recent build, I pulled down a daily build (62520) and tried it again. Still hangs for me (running NT4 SP6a). Produced a talkback report again (incident ID TB13139636Y).

Layout takes about 3 minutes on my K6-300 with Build 061820 on Win98. After switching to another program and then back to Mozilla it takes 3 minutes again to "unfreeze" Mozilla window...

with 62708 winME, this now freezes

Triaging Clayton's list: -------------------------- Yup, it does freeze ( 06/29/00 build ). Here is the trace: nsCellMap::GetMapCellAt(nsTableCellMap & {...}, int 18, int 241, int 1) line 1656 + 13 bytes nsCellMap::GetCellAt(nsTableCellMap & {...}, int 18, int 241) line 1708 nsTableCellMap::GetCellAt(int 18, int 241) line 246 + 20 bytes nsTableBorderCollapser::ComputeRightBorderForEdgeAt(nsIPresContext * 0x02637c80, int 18, int 183) line 276 + 16 bytes nsTableBorderCollapser::ComputeVerticalBorders(nsIPresContext * 0x02637c80, int 0, int -1) line 167 nsTableFrame::Reflow(nsTableFrame * const 0x00dba588, nsIPresContext * 0x02637c80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 1571 nsContainerFrame::ReflowChild(nsIFrame * 0x00dba588, nsIPresContext * 0x02637c80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0, unsigned int 3, unsigned int & 0) line 693 + 31 bytes nsTableOuterFrame::OuterReflowChild(nsTableOuterFrame * const 0x00dba534, nsIPresContext * 0x02637c80, nsIFrame * 0x00dba588, const nsHTMLReflowState & {...}, nsHTMLReflowMetrics & {...}, int * 0x00000000, nsSize & {...}, nsMargin & {...}, nsMargin & {...}, nsReflowReason eReflowReason_Initial, unsigned int & 0) line 885 + 47 bytes nsTableOuterFrame::Reflow(nsTableOuterFrame * const 0x00dba534, nsIPresContext * 0x02637c80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 1419 + 59 bytes nsBlockReflowContext::DoReflowBlock(nsHTMLReflowState & {...}, nsReflowReason eReflowReason_Initial, nsIFrame * 0x00dba534, const nsRect & {...}, int 0, int 0, int 1, nsMargin & {...}, unsigned int & 0) line 563 + 36 bytes nsBlockReflowContext::ReflowBlock(nsIFrame * 0x00dba534, const nsRect & {...}, int 0, int 0, int 1, nsMargin & {...}, unsigned int & 0) line 388 + 50 bytes nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineBox * 0x02460e8c, int * 0x0012de30) line 3928 + 56 bytes nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineBox * 0x02460e8c, int * 0x0012de30, int 1) line 3192 + 23 bytes nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2999 + 27 bytes nsBlockFrame::Reflow(nsBlockFrame * const 0x00dba45c, nsIPresContext * 0x02637c80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 1765 + 15 bytes nsBlockReflowContext::DoReflowBlock(nsHTMLReflowState & {...}, nsReflowReason eReflowReason_Incremental, nsIFrame * 0x00dba45c, const nsRect & {...}, int 1, int 0, int 1, nsMargin & {...}, unsigned int & 0) line 563 + 36 bytes nsBlockReflowContext::ReflowBlock(nsIFrame * 0x00dba45c, const nsRect & {...}, int 1, int 0, int 1, nsMargin & {...}, unsigned int & 0) line 388 + 50 bytes nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineBox * 0x00dba4d0, int * 0x0012e988) line 3928 + 56 bytes nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineBox * 0x00dba4d0, int * 0x0012e988, int 1) line 3192 + 23 bytes nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2999 + 27 bytes nsBlockFrame::Reflow(nsBlockFrame * const 0x00dba3d4, nsIPresContext * 0x02637c80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 1765 + 15 bytes nsContainerFrame::ReflowChild(nsIFrame * 0x00dba3d4, nsIPresContext * 0x02637c80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0, unsigned int 0, unsigned int & 0) line 693 + 31 bytes CanvasFrame::Reflow(CanvasFrame * const 0x00db9744, nsIPresContext * 0x02637c80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 306 nsBoxToBlockAdaptor::Reflow(nsBoxLayoutState & {...}, nsIPresContext * 0x02637c80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0, int 0, int 0, int 9180, int 3885, int 1) line 796 nsBoxToBlockAdaptor::Layout(nsBoxToBlockAdaptor * const 0x00dba378, nsBoxLayoutState & {...}) line 467 + 52 bytes nsScrollPortFrame::Layout(nsScrollPortFrame * const 0x00db9858, nsBoxLayoutState & {...}) line 361 nsContainerBox::LayoutChildAt(nsBoxLayoutState & {...}, nsIBox * 0x00db9858, const nsRect & {...}) line 613 + 16 bytes nsGfxScrollFrameInner::LayoutBox(nsBoxLayoutState & {...}, nsIBox * 0x00db9858, const nsRect & {...}) line 1016 + 17 bytes nsGfxScrollFrameInner::Layout(nsBoxLayoutState & {...}) line 1104 nsGfxScrollFrame::Layout(nsGfxScrollFrame * const 0x00db97b8, nsBoxLayoutState & {...}) line 1029 + 15 bytes nsBoxFrame::Reflow(nsBoxFrame * const 0x00db9780, nsIPresContext * 0x02637c80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 651 nsGfxScrollFrame::Reflow(nsGfxScrollFrame * const 0x00db9780, nsIPresContext * 0x02637c80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 715 + 25 bytes nsContainerFrame::ReflowChild(nsIFrame * 0x00db9780, nsIPresContext * 0x02637c80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0, unsigned int 0, unsigned int & 0) line 693 + 31 bytes ViewportFrame::Reflow(ViewportFrame * const 0x00db9708, nsIPresContext * 0x02637c80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 546 nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x02c6d220, nsIPresContext * 0x02637c80, nsHTMLReflowMetrics & {...}, const nsSize & {...}, nsIRenderingContext & {...}) line 145 PresShell::ProcessReflowCommands Looks like TABLE to me. Over to karnaze@netscape.com.

I'm not seeing a freeze or crash, but nothing is displayed. Eric, can you take a look, since there is a frameset.

Don't think this is a frameset issue - the pages inside the frameset won't load by themselves: http://www.nordpool.no/products/financial/prod_kalender/Prod.kalender-filer/shee t001.htm Interestingly, this page is written out by "Microsoft Excel 9" and there is lots of funky markup. I don't know what's up with that page loading, but I'm going to attach the original test case here so we don't loose the 'hang' bug.

I reduced this to a page that shows the 'hang' problem. Giving it back to you, Chris, because it looks like tables. Still looking at the 'page not loading' problem, but it doesn't look like a frameset issue. The problem seems to be <col> tags. (Table columns). When I removed the <col>'s from the test case I'm about to attach, the page layed out very quickly. With the <col>'s, there was a penalty of something like 8 seconds per row on the Sparc Ultra-2 I was running on (hundreds of rows -> long, long, long delays)

The slowdown is due to the collapsing border code. I'm marking this dependent on bug 41262.

to quote my response to http://bugzilla.mozilla.org/show_bug.cgi?id=42728 , which was the original version of this bug: I've been trying this in various Mozilla versions over time and it seems to be MUCH improved in Mozilla 0.6 (Win32 version running on NT 4.0 SP6a). There may be a bit of extra whitespace on sheet004.htm, but this is as nothing compared to the original problem and, given the nature of HTML and XML, may just be a matter of taste. Also, I have recently downloaded 0.7 and it's still working (implying a stable fix, if I'm lucky)

Moving to m1.0

I just tested the original url on Mozilla build id 2001031611 on Linux on my P-II 233MHz/128MB and it renders within seconds, only freezing the browser for up to one second and it does not hog the CPU. Can anybody confirm?

WFM 2001060804/WinXP/K6-III-500/192MB RAM

Collapsing borders were disabled some time ago, so this should be WFM, but please leave this bug open and dependent on bug 41262.

Removing hang and crash keywords.

->m099

Marking nsbeta1+

With the new collapsing border code checked in, I'm getting the following assertion and cannot tell how long it takes to load the page. nsDebug::Assertion(const char * 0x02e6f830, const char * 0x02e6f824, const char * 0x02e6f7f0, int 4881) line 291 + 13 bytes BCMapCellIterator::SetInfo(nsTableRowFrame * 0x05e6e6c0, int 9, CellData * 0x05c504b8, BCMapCellInfo & {...}, nsCellMap * 0x00000000) line 4881 + 35 bytes BCMapCellIterator::Next(BCMapCellInfo & {...}) line 5005 nsTableFrame::CalcBCBorders(nsIPresContext & {...}) line 5765 + 38 bytes

Comment on attachment 70716 [details] [diff] [review] patch to fix assertion and allow border collapsing calculations traverse a col arosss a col group r= alexsavulov are you sure you want to remove 'const' from nsTableFrame::GetEffectiveRowSpan?

Comment on attachment 70716 [details] [diff] [review] patch to fix assertion and allow border collapsing calculations traverse a col arosss a col group sr=attinasi

The patch is in.

Comment on attachment 72475 [details] [diff] [review] revised patch fixing a typo a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Does not hang or crash any more. Build : 2002031303