We're probably doing this for now, given we are storing the change hint in the style context, which lives in the frame.
In stock Gecko, when we have new content inserted into the document, it should get frames constructed for it either immediately under the nsCSSFrameConstructor::ContentAppended notification, or that method will set flags on the node to lazily create frames once we call CreateNeededFrames() from within RestyleManager::ProcessPendingRestyles. Can we do the same here? I'm not sure why we need to generate nsChangeHint_ReconstructFrame here. A related point is that since RestyleManager traverses the frame tree, it will not restyle down into content with no frames. Well, it will try restyling the undisplayed children of a node with a frame, since we might need to restyle them from display:none to display:block for example, but otherwise won't go any further.
So I was not talking about ContentAppended, but changes from display: none to block, for example. Basically, if we arrive to an content without frame we do the equivalent of nsChangeHint_ReconstructFrame. (I'm about to upload a few patches to bug 1290335, doing the rebase and sanity-check build right now that does it). But I was wondering when I filled the bug if we could do better than that (probably?).
This is not an issue anymore.