Open Bug 613816 Opened 11 years ago Updated 7 years ago

"ASSERTION: Why did this not get handled while processing mRestyleRoots?" due to parent frame not knowing about anonymous content created by editor

Categories

(Core :: DOM: Editor, defect)

x86
macOS
defect
Not set
normal

Tracking

()

People

(Reporter: jruderman, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, testcase)

Attachments

(5 files)

Attached file testcase
###!!! ASSERTION: Why did this not get handled while processing mRestyleRoots?: '!element->HasFlag(collector->tracker->RootBit()) || (element->GetFlattenedTreeParent() && (!element->GetFlattenedTreeParent()->GetPrimaryFrame()|| element->GetFlattenedTreeParent()->GetPrimaryFrame()->IsLeaf())) || (aData.mChangeHint & nsChangeHint_ReconstructFrame)', file layout/base/RestyleTracker.cpp, line 120

See also bug 574238, which has a XUL testcase.
Attached file stack trace
CCing dbaron as he might have an idea what's going on here...
What's going on is that the resizer stuff in editor is broken, of course.  ;)

Specifically, we land in nsHTMLEditor::CheckSelectionStateForAnonymousButtons from the end of an update view batch for the insertHTML call, which calls ShowResizers for the <table>.  ShowResizers goes and creates some anon nodes and binds them to the tree and calls RecreateFramesFor (see nsHTMLEditor::CreateAnonymousElement).  This last does nothing because we have no frame for the <body> at this point.

So now we have these nodes.  They're in the restyle tracker (due to attr changes on them after we bound them).  They're bound to the DOM.  When the <body> gets a frame, they don't (this is a bug, note!) because nothing outside editor really knows about them.  Then restyle processing can't find them (since it only looks in the frame tree and undisplayed map and they're in neither), and we get the assert this bug is about.  But the real issue is the resizers have no frames when all this code has run...
Why don't these anonymous content nodes get a frame when one is created for body?  They're bound to the DOM at that point, right?
Yes, but they're anonymous.  So their parent knows nothing about them.  They're not normal frame-created anonymous content, so nsIAnonymousContentCreator knows nothing about them.  They're not XBL, so the binding manager knows nothing about them.

So the frame constructor has no way to know they even exist.
If the point is that maybe we should have a way to tell the frame constructor about them, that seems like a fine approach to me, which would fix a number of random issues we've run into with these resizers, I suspect.
(In reply to comment #6)
> If the point is that maybe we should have a way to tell the frame constructor
> about them, that seems like a fine approach to me, which would fix a number of
> random issues we've run into with these resizers, I suspect.

Yes, that was what I had in mind.
Blocks: 574238
Jesse, do you happen to have a testcase for this that still reproduces the bug?  (I'm pretty sure the bug is still present; this testcase just now has a JS error.)
Flags: needinfo?(jruderman)
Bug 439258 is also related.
I think this stack explains why the assertions here are no longer reproducable, even though the underlying problem still exists.

In particular, this stack shows us flushing style immediately before (in nsHTMLEditor::CheckSelectionStateForAnonymousButtons) posting the restyles for the resizer frames.  This means that when those restyles are posted today, they can't have an ancestor with a restyle posted -- at least not in any easy-to-manipulate way -- which means the restyles always get put in the restyle roots list, and we don't get the assertion.
Flags: needinfo?(jruderman)
Attached file testcase 3
This repros the assertion on trunk. Hopefully it's the same bug.
Flags: needinfo?(dbaron)
Summary: "ASSERTION: Why did this not get handled while processing mRestyleRoots?" → "ASSERTION: Why did this not get handled while processing mRestyleRoots?" due to parent frame not knowing about anonymous content created by editor
You need to log in before you can comment on or make changes to this bug.