It'd be nice from the layout point of view if we had a cheap way to get the flattened tree previous / next sibling of a given element. Right now the only way to properly traverse the flat tree is using GetFlattenedTreeParent() and FlattenedChildIterator, it'd be nice to have something like: class FlattenedTree { public: static nsIContent* Parent(const nsIContent&); static nsIContent* NextSibling(const nsIContent&); static nsIContent* PrevSibling(const nsIContent&); static nsIContent* FirstChild(const nsIContent&); static nsIContent* LastChild(const nsIContent&); }; (Or something of the sort) This would allow simplifying the frame constructor a lot, actually.

Boris, Olli, does this sound something worth pursuing? This would allow us to fix a bunch of display: contents insertion point bugs (esp. related to pseudo-elements), and fix bug 1404789 easily, I think. I suspect it may not be that hard to implement and make fast, I can try to give it a shot if it sounds ok. I just want to make sure this hasn't been attempted before / there isn't any reason why this isn't doable, before going ahead.

I guess FlattenedChildIterator::Seek + GetNextChild / GetPreviousChild does the job, but what do people think of having the API proposed above, and implementing FlattenedChildIterator on top of it.

(Plus Seek is slow in the "not a light tree child" case I guess)

Relevant IRC conversation: http://logs.glob.uno/?c=mozilla%23content&s=10+Oct+2017&e=10+Oct+2017#c465167

I think this is a really good idea, fwiw. As long as a pointer to a node is enough to make the API fast... One benefit of the iterator approach is that it can cache state as needed, in theory. Whether that happens in practice, I haven't checked. In any case, even if we had an iterator object, I'd vote for being able to initialize it with a node and then walk it around the tree, not what we have now.