Closed
Bug 6937
Opened 25 years ago
Closed 25 years ago
Possible view heirarchy issues
Categories
(Core :: Layout, defect, P1)
Tracking
()
VERIFIED
FIXED
M9
People
(Reporter: buster, Assigned: troy)
References
()
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.
Peter, since you know frame construction better than I do, perhaps you can take
a quick look?
Updated•25 years ago
|
Assignee: peterl → kipp
Comment 3•25 years ago
|
||
A line box frame has a garbage view pointer. Kipp's baby.
Updated•25 years ago
|
Target Milestone: M7 → M15
Comment 4•25 years ago
|
||
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.
Updated•25 years ago
|
Target Milestone: M15 → M7
Comment 6•25 years ago
|
||
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.
Updated•25 years ago
|
Summary: crash in nsFrame::DeleteFrame going to zdnet → crash in nsFrame::DeleteFrame going to zdnet - peterl?
Updated•25 years ago
|
Assignee: kipp → peterl
Summary: crash in nsFrame::DeleteFrame going to zdnet - peterl? → top100 -> crash in nsFrame::DeleteFrame going to zdnet - peterl for kipp?
Updated•25 years ago
|
Assignee: peterl → troy
Summary: top100 -> crash in nsFrame::DeleteFrame going to zdnet - peterl for kipp?
Target Milestone: M7 → M9
Comment 8•25 years ago
|
||
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.
Updated•25 years ago
|
Summary: Possible view heirarchy issues
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: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 10•25 years ago
|
||
QA: my fix can't be verified by QA
Changed ConstructFrameByDisplayType() to use the correct parent frame pointer
for floated elements
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 11•25 years ago
|
||
Marking verified fixed.
You need to log in
before you can comment on or make changes to this bug.
Description
•