The above page crashes apprunner. What happens is: 1) It loads, going through some bad display that looks like bug 5849, but worse, since some of the things displayed are garbage rather than the previous page. 2) The display becomes fine. 3) A fraction of a second later, apprunner crashes (according to Norton CrashGuard). This also could be related to bug 1596.

This crashes on 4/30 debug WinNT in Apprunner and sometimes in Viewer. Here is the stack which looks web shell related. Reassigning to Nisheeth. NTDLL! 77f76148() nsWindow::Create(nsWindow * const 0x018205d4, nsIWidget * 0x00000000, const nsRect & {x=0 y=0 width=0 height=0}, nsEventStatus (nsGUIEvent *)* 0x040339ba HandleEvent(nsGUIEvent *), nsIDeviceContext * 0x017cc200, nsIAppShell * 0x00000000, nsIToolkit * 0x00000000, nsWidgetInitData * 0x00000000) line 648 nsView::CreateWidget(nsView * const 0x01820500, const nsID & {...}, nsWidgetInitData * 0x00000000, void * 0x00000000) line 1210 DocumentViewerImpl::MakeWindow(void * 0x00000000, const nsRect & {x=0 y=0 width=0 height=0}, nsScrollPreference nsScrollPreference_kAuto) line 626 + 32 bytes DocumentViewerImpl::Init(DocumentViewerImpl * const 0x01807650, void * 0x00000000, nsIDeviceContext * 0x017cc200, nsIPref * 0x016dea40, const nsRect & {x=0 y=0 width=0 height=0}, nsScrollPreference nsScrollPreference_kAuto) line 319 nsWebShell::Embed(nsWebShell * const 0x017cbe10, nsIContentViewer * 0x01807650, char * 0x017ccfd0, nsISupports * 0x00000000) line 735 + 69 bytes nsDocumentBindInfo::OnStartBinding(nsDocumentBindInfo * const 0x017ccf80, nsIURL * 0x017cc5b0, char * 0x01806ed0) line 2000 + 36 bytes OnStartBindingProxyEvent::HandleEvent(OnStartBindingProxyEvent * const 0x01806e80) line 506 StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x01806e84) line 471 + 12 bytes PL_HandleEvent(PLEvent * 0x01806e84) line 476 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x016de650) line 437 + 9 bytes _md_EventReceiverProc(void * 0x001d0162, unsigned int 49330, unsigned int 0, long 23979600) line 799 + 9 bytes

Accepting bug. Setting TFV to M5 for now.

Here's what happens. When the load of the external CSS stylesheet (style/default) completes, the frame model gets thrown away and recreated. As each frame gets destroyed it destroys the associated view which destroys the associated widget. The problem is that nsHTMLFrameInnerFrame's destructor does not destroy the webshell contained by it. So this webshell continues to maintain a dangling pointer to the widget. Later, the doc loader associated with the webshell attempts to embed a document viewer in the pseudo-dead webshell by calling nsWebShell::Embed() . nsWebShell::Embed() assumes that the widget is still around and ends up causing a crash. A temporary fix for this is to call nsWebshell::Stop() from nsHTMLFrameInnerFrame's destructor. The right fix is to actually destroy the webshell in nsHTMLFrameInnerFrame's destructor and fix up the webshell code that currently tries to destroy children webshells when it loads a new page. Kipp and me think that we should put in the temporary fix for M5 and the right one for M6. I'm going to test apprunner with the M5 fix on the set of smoketest urls. If everything looks good, I'll check it into the branch. Kipp, please feel free to add clarifications to the above.

The "right" fix is checked in on the tip. Chris Hofmann has asked me to hold off on the checkin of the temporary fix to the M5 branch because we may not be re-spinning the builds that are currently under QA. If we do, I'll check the temp fix into the branch. The changes that got checked in on the tip are as follows. A RemoveChild() method was added to nsIWebShell. nsWebShell::Destroy() calls this method on its parent to remove itself from the parent's child list. Also, nsHTMLFrameInnerFrame's destructor now calls nsWebShell::Destroy() so that the webshell associated with the HTML frame's nsFrame gets destroyed at the same time as the nsFrame.

accessing the frames page no longer carshes the app on win95 using the M5 release 19990505, however, the initial layout of the page is still undesireable. It initially appears like scan lines going across the page, then redraws displaying the frames -- but I will open a new bug for that particular problem.

The display problem (with another page) is already bug 5849.