nsFrame::DeleteFrame crashes every time I go to zdnet. mView is garbage in the following code snippet: //Set to prevent event dispatch during destruct if (nsnull != mView) { mView->SetClientData(nsnull); } The stack is: nsFrame::DeleteFrame() line 373 + 17 bytes nsLineBox::DeleteLineList() line 158 nsBlockFrame::DeleteFrame() line 806 + 16 bytes nsLineBox::DeleteLineList() line 158 nsBlockFrame::DeleteFrame() line 806 + 16 bytes nsAreaFrame::DeleteFrame() line 106 nsFrameList::DeleteFrames() line 29 nsContainerFrame::DeleteFrame() line 82 nsFrameList::DeleteFrames() line 29 nsContainerFrame::DeleteFrame() line 82 nsFrameList::DeleteFrames() line 29 nsContainerFrame::DeleteFrame() line 82 nsFrameList::DeleteFrames() line 29 nsContainerFrame::DeleteFrame() line 82 nsTableFrame::DeleteFrame() line 341 nsFrameList::DeleteFrames() line 29 nsContainerFrame::DeleteFrame() line 82 nsLineBox::DeleteLineList() line 158 nsBlockFrame::DeleteFrame() line 806 + 16 bytes nsAreaFrame::DeleteFrame() line 106 nsFrameList::DeleteFrames() line 29 nsContainerFrame::DeleteFrame() line 82 nsFrameList::DeleteFrames() line 29 nsContainerFrame::DeleteFrame() line 82 nsFrameList::DeleteFrames() line 29 nsContainerFrame::DeleteFrame() line 82 nsFrameList::DeleteFrames() line 29 nsContainerFrame::DeleteFrame() line 82 nsTableFrame::DeleteFrame() line 341 nsFrameList::DeleteFrames() line 29 nsContainerFrame::DeleteFrame() line 82 nsFrameList::DeleteFrames() line 29 nsBlockFrame::DeleteFrame() line 811 nsLineBox::DeleteLineList() line 158 nsBlockFrame::DeleteFrame() line 806 + 16 bytes nsAreaFrame::DeleteFrame() line 106 nsFrameList::DeleteFrame() line 115 RootFrame::Reflow() line 191 nsContainerFrame::ReflowChild() line 392 + 28 bytes nsScrollFrame::Reflow() line 413 nsContainerFrame::ReflowChild() line 392 + 28 bytes ViewportFrame::Reflow() line 438 nsHTMLReflowCommand::Dispatch() line 169 PresShell::ProcessReflowCommands() line 1237 PresShell::ExitReflowLock() line 656 PresShell::ReconstructFrames() line 1701 PresShell::StyleSheetAdded() line 1709 nsDocument::InsertStyleSheetAt() line 1356 CSSLoaderImpl::InsertSheetInDoc() line 832 InsertPendingSheet() line 493 nsVoidArray::EnumerateForwards() line 213 + 20 bytes CSSLoaderImpl::Cleanup() line 543 CSSLoaderImpl::SheetComplete() line 599 CSSLoaderImpl::ParseSheet() line 627 CSSLoaderImpl::DidLoadStyle() line 652 + 20 bytes DoneLoadingStyle() line 483 nsUnicharStreamLoader::OnStopBinding() line 156 + 31 bytes nsDocumentBindInfo::OnStopBinding() line 1523 + 30 bytes OnStopBindingProxyEvent::HandleEvent() line 592 + 45 bytes StreamListenerProxyEvent::HandlePLEvent() line 472 + 12 bytes PL_HandleEvent() line 491 + 10 bytes PL_ProcessPendingEvents() line 452 + 9 bytes _md_EventReceiverProc() line 868 + 9 bytes

can't get through the top 100 until this is fixed. Peter might be the best person to look through this initially, because style sheet loading is on the bottom of the stack, triggering the crash. It might be unrelated, but it's a place to start. Leaving assigned to Rick, cc Peter.

Peter, since you know frame construction better than I do, perhaps you can take a quick look?

A line box frame has a garbage view pointer. Kipp's baby.

Kipp is on sabbatical. Marking bug M15.

cc'ing Rick. I don't think we have the luxury of assigning crashers to M15 just because they're in Kipp's code. Even though it might be painful, I think it should be assigned to someone in layout, prioritized against other bugs, and fixed sooner than "a long time from now" which is what M15 means.

Agrereed, this wasn't assigned to Kipp to push it off until he returns. It was assigned to him to keep problems in his code grouped together. It's expected that others (most likely me) will step in here and fix it anyway before he returns.

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

The crash is now fixed. I think there is an underlying problem with view parentage. This crash was caused by a floating child containing a frame with a view moving outside a parent who also had a view. In this situation, the view heirarchy gets out of sync with the frame geometric heirarchy. Troy, please look into the view parentage and lets talk about if this should work this way. A simple test case: <div style="opacity:50%; display:inline"><div style="float: right"><span style="opacity:50%"></span></div></div> Note how the view parent of the inner span is the outer div, but the geometric frame parent of the inner span is the body. I fixed the crasher by making the block parent delete the floater frames before deleting children.

That's whacky and it shouldn't be that way. The view and frame hierarchies should be consistent. I'll take a look

QA: my fix can't be verified by QA Changed ConstructFrameByDisplayType() to use the correct parent frame pointer for floated elements

Marking verified fixed.