Possible view heirarchy issues

VERIFIED FIXED in M9

Status

()

defect
P1
critical
VERIFIED FIXED
20 years ago
20 years ago

People

(Reporter: buster, Assigned: troy)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

()

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
Severity: normal → critical
Priority: P3 → P1
Target Milestone: M7
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.
Assignee: rickg → peterl
Peter, since you know frame construction better than I do, perhaps you can take
a quick look?
Assignee: peterl → kipp
A line box frame has a garbage view pointer. Kipp's baby.
Target Milestone: M7 → M15
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.
Target Milestone: M15 → M7
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. ***
Summary: crash in nsFrame::DeleteFrame going to zdnet → crash in nsFrame::DeleteFrame going to zdnet - peterl?
Assignee: kipp → peterl
Summary: crash in nsFrame::DeleteFrame going to zdnet - peterl? → top100 -> crash in nsFrame::DeleteFrame going to zdnet - peterl for kipp?
Assignee: peterl → troy
Summary: top100 -> crash in nsFrame::DeleteFrame going to zdnet - peterl for kipp?
Target Milestone: M7 → M9
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.
Summary: Possible view heirarchy issues
Status: NEW → ASSIGNED
That's whacky and it shouldn't be that way. The view and frame hierarchies
should be consistent. I'll take a look
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
QA: my fix can't be verified by QA

Changed ConstructFrameByDisplayType() to use the correct parent frame pointer
for floated elements
Status: RESOLVED → VERIFIED
Marking verified fixed.
You need to log in before you can comment on or make changes to this bug.