Closed Bug 1140160 Opened 5 years ago Closed 5 years ago

"ASSERTION: Unexpected parent" and "MOZ_CRASH(nsFieldSetFrame::InsertFrames not supported)"

Categories

(Core :: Layout, defect, critical)

defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: mats)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, crash, testcase)

Attachments

(3 files)

Attached file testcase
###!!! ASSERTION: Unexpected parent: 'parentFrame->GetType() != nsGkAtoms::fieldSetFrame', file layout/base/nsCSSFrameConstructor.cpp, line 7142

Hit MOZ_CRASH(nsFieldSetFrame::InsertFrames not supported) at layout/forms/nsFieldSetFrame.cpp:661

Even the crash is debug-only (it's in a big ifdef debug).
Attached file stack
I think roc added that MOZ_CRASH.
I can take a look since it's likely caused by the display:contents.
Assignee: nobody → mats
Something somewhere is missing a GetContentInsertionFrame(), clearly..
Blocks: 1140579
(In reply to Not doing reviews right now from comment #4)
> Something somewhere is missing a GetContentInsertionFrame(), clearly..

Hmm, nsFieldSetFrame doesn't have a GetContentInsertionFrame() method and
I don't think it ever did.  I think bug 496840 is what changed frame construction
so that nsFieldSetFrame::Insert/Append/RemoveFrames wouldn't be called
at all.  Before that change, I think it was called only for legend frames.
(bug 931464 later removed the code and made those methods assert if called)

Anyway, what normally happens is: GetInsertionPoint would flag this
as a "multiple insertion points" situation:
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp?rev=c6c310429562#8911

Then we'll either re-create the whole fieldset frame subtree:
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp?rev=c6c310429562#7579

or do an insertion, which leads to GetInsertionPrevSibling, which has a side-effect
of also fixing up the parent frame for fieldsets by calling GetAdjustedParentFrame:
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp?rev=c6c310429562#6596
which returns the right parent depending on the child:
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp?rev=c6c310429562#6488
OS: Mac OS X → All
Hardware: x86_64 → All
Attached patch fix+testsSplinter Review
This adds a GetAdjustedParentFrame on the relevant display:contents path
in GetInsertionPrevSibling.  I also clarified a comment that's a bit
confusing.

(there's still an issue that <legend>s don't get the right frame type
in this situation, but it's a separate issue so I filed bug 1140579)

https://treeherder.mozilla.org/#/jobs?repo=try&revision=4d49ebb63997
Attachment #8574202 - Flags: review?(roc)
https://hg.mozilla.org/integration/mozilla-inbound/rev/3fef33215d39
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.