If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

NEW
Unassigned

Status

()

Core
Editor
7 years ago
3 years ago

People

(Reporter: Jesse Ruderman, Unassigned, NeedInfo)

Tracking

(Blocks: 2 bugs, {assertion, testcase})

Trunk
x86
Mac OS X
assertion, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

7 years ago
Created attachment 492136 [details]
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.
(Reporter)

Comment 1

7 years ago
Created attachment 492138 [details]
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: 946442
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.
Created attachment 8412951 [details]
stack explaining why bug is no longer reproducable even though underlying problem still exists

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.
Created attachment 8412953 [details]
testcase I was attempting to use
Flags: needinfo?(jruderman)
(Reporter)

Comment 12

3 years ago
Created attachment 8428325 [details]
testcase 3

This repros the assertion on trunk. Hopefully it's the same bug.
(Reporter)

Updated

3 years ago
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.