Example number 4 in the debug viewer menu contains a table that displays correctly if viewed separately - see http://schist/bogus.html - but if it is viewed in the context of the entire example 4 document, it does not display correctly. Worse yet, if you view it as a non local file using the above url, when you scroll down to look at that table, it will crash the browser. what follows is a dr watson log for your amusement. APPRUNNER caused an invalid page fault in module RAPTORVIEW.DLL at 0177:018d5c4f. Registers: EAX=00000000 CS=0177 EIP=018d5c4f EFLGS=00010246 EBX=00c893f0 SS=017f ESP=0076f17c EBP=0076f294 ECX=0076f270 DS=017f ESI=019a0220 FS=6547 EDX=00000000 ES=017f EDI=00000000 GS=0000 Bytes at CS:EIP: 8b 08 52 8b 55 dc f7 da 52 50 ff 51 68 8b 55 e0 Stack dump: 00c893f0 01964ab0 019a0220 5e562016 5e560637 81d20637 00017d8f 8df70000 81d20282 00005ca2 81e20617 04a7553c 06375e56 5e480020 81e20617 04a75574

Table 3 in example 4 is horked in an optimized build only. I'm Changing the summary to reflect this.

Regarding the 1st part of the bug, the table displays differently (both are correct) when viewed separately because in sample 4 multiple tables are inside a div and there is relative positioning involved. I will change sample 4 to not do this because it is confusing. Regarding the crash, this occurs in Apprunner, not Viewer. I tried it on 4/26 optimizied WinNT. Reassigning to Peter and moving to M6.

*** Bug 5036 has been marked as a duplicate of this bug. ***

reassigning to RickG. Rick, this is a crash in HTML tables that has no apparent relation to XPToolkit other than that some of our code is also in that application. I have no idea why this and other similar bugs are being assigned to me. If there were a stack trace that implicates XUL or some XPToolkit module, or a comment about some XPToolkit connection I'd understand, but this seems pretty random.

Peter, The criteria for reassigning bugs to you is very simple - If it works in Viewer but not Apprunner, then you get it. If someone else is responsible for Apprunner and/or this is not acceptable to you, please call me and we can discuss it further.

Don Melton is responsible for AppRunner, but this is most certainly NOT acceptable, either to me or to him. Don's team is not automatically responsible for all AppRunner-specific bugs, and making that a policy is just wrong.

Chris -- I'm working on est. a clearcut policy on how to hand off bugs, but one thing you need to do is gather at least *some* concrete evidence that this is an apprunner bug, and not just one of your bugs that only shows up in apprunner. I suggest a stack trace.

See http://cyclone.mcom.com/reports/incidenttemplate.CFM?reportID=124&style=0&tc=27& cp=1&ck1=SUser+email+address&cd1=%25cpratt%40netscape%2Ecom%25&co1=like&bbid=854 5111 for the talkback report. Line 1200 of nsViewManager follows: 1200 mRedCX->Translate(-localrect.x, -localrect.y); Call Stack: (Signature = nsViewManager::RenderViews f7aed193) nsViewManager::RenderViews [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1200] nsViewManager::Refresh [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 521] nsViewManager::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1646] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 67] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 414] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 431] nsWindow::OnPaint [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2800] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2166] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 475] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x242e7 (0xbff942e7)

Reassigning to Patrick.

Doesn't crash mac, but does emit a lot of warnings: "WARNING - a non table row contains a table cell child." No clue. Perhaps Kevin can shine some light on this.

The warning is not critical. It indicates that something other than a <TR> included a <TD>. The reason I reassigned the bug to Patrick is because the stack included nsViewManager. I'm not sure who handles what these days in the view system.

Looks like the view has been destroyed, but there is still a native window which knows about it. An event get's dispatched to the destroyed view causing a crash since fields in the view are null'ed out in it's destructor. Patrick, I'm re-assigning back to you, it looks like a view/event issue.

1. scrolling views within scrolling views don't work right. this has been a known problem that I'm hoping to tackle by M7 (maybe M6) 2. there was a lot of bogus ref counting in nsScrollingView.cpp, many calls to GetWidget() and QueryInterface() that weren't followed by NS_RELEASE. The code is confusing, because some of the QueryInterface() calls that aren't followed by NS_RELEASE are correct, because views don't reference count. However, the widget and QueryInterface on nsIWidget's do. This may have been the source of crashing. I've checked in fixes for this in revision 3.102 of nsScrollingView.cpp.

moving to m9. beard's on vacation

I've already got bugs filed regarding the scrolling problems. The crasher seems to have been eliminated, so I'm going to mark it as fixed.

Verified fixed regarding the crash issue.