Closed Bug 481806 Opened 11 years ago Closed 10 years ago

"ASSERTION: Unexpected PopupSetFrame" with <xul:hbox> as root of HTML document

Categories

(Core :: Layout, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla1.9.1b3

People

(Reporter: jruderman, Assigned: bzbarsky)

References

(Blocks 2 open bugs)

Details

(Keywords: assertion, regression, testcase)

Attachments

(1 file)

Attached file testcase
###!!! ASSERTION: Unexpected PopupSetFrame: 'nsIRootBox::GetRootBox(mPresShell) && nsIRootBox::GetRootBox(mPresShell)->GetPopupSetFrame() == newFrame', file /Users/jruderman/central/layout/base/nsCSSFrameConstructor.cpp, line 5179

I think this is a regression from within the last 2 days.
Sort of, yes.  This is a regression from bug 480979.  That said, it points out a real problem that existed before that.  After the hbox is inserted, the frame tree near the root is:

Viewport
  HTMLScroll(html)
    [snipped scrollbars and scrollcorners]
    Canvas(html)
      DocElementBox(hbox)

That's very much broken.
Assignee: nobody → bzbarsky
Blocks: 480979
So there are all sorts of ways I could silence the assert and go back to the old behavior here, I think.  But ideally we'd just get the frame tree right...  That basically means removing everything except the ViewportFrame when the root element is removed, and recreating those frames when it's readded.  roc, do you know why we don't do that now?
See also bug 78070, where we discuss the same thing.  Shall we just fix it?  roc, you want to do it, or should I take a stab?
As part of doing this, or a prereq, I should consider getting rid of ReconstructDocElementHierarchyInternal.  See bug 480880 comments.
Target Milestone: --- → mozilla1.9.1b3
The patch in bug 78070 fixes this.
Depends on: 78070
Fixed by fix for bug 78070.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.