###!!! ASSERTION: Why did this not get handled while processing mRestyleRoots?: '!element->HasFlag(collector->tracker->RootBit()) || (element->GetFlattenedTreeParent() && (!element->GetFlattenedTreeParent()->GetPrimaryFrame() || element->GetFlattenedTreeParent()->GetPrimaryFrame()->IsLeaf() || element->GetCrossShadowCurrentDoc()->GetShell()->FrameManager() ->GetDisplayContentsStyleFor(element))) || (aData->mChangeHint & nsChangeHint_ReconstructFrame)', file layout/base/RestyleTracker.cpp, line 136 Based on reading bug 1012527, I'm guessing the timeout in the testcase corresponds to "wait for paints".

Hmmm. When we decide to reframe an element (and thus not continue the restyle on it or its descendants in ElementRestyler::Restyle), is there someplace that we clear out the restyles on its descendants? It seems like that's a sensible thing to do, but I don't remember having code for it, and it seems like this assertion would depend on such code. Then again, I haven't debugged this; it could depend on something fancy with heycam's recent optimizations.

> is there someplace that we clear out the restyles on its descendants? I don't think so, but the actual reframe will clear them out, I believe.