Martijn Wargers (dead) Reporter
	Description • 19 years ago

See upcoming testcase, it gives this assertion on load in a recent debug Firefox build:
###!!! ASSERTION: next-in-flow has different content: '!kidFrame || parentFrame-
>GetContent() == aParentContent', file c:/mozilla/mozilla/layout/base/nsCSSFrame
Constructor.cpp, line 11092

	Mats Palmgren (inactive) Assignee
	Comment 2 • 19 years ago

http://webtools.mozilla.org/bonsai/cvsblame.cgi?file=mozilla/layout/base/nsCSSFrameConstructor.cpp&rev=1.1172&root=/cvsroot&mark=11092-11096,11100,11104-11107,11110#11061

We're looking for content (cyan) in a descendent of aParentFrame (red).
Starting at the "hint frame" (blue) [line 11092] (since it's an
out-of-flow we change it to the placeholder [11095]),
the placeholder has no next sibling [11100] so we try to find
a next-in-flow/special-sibling for the parent [11106] so we can
continue with that frame's first child [11110].
This seems reasonble, the problem is that we are using the original
hint frame, an out-of-flow in this case, whos parent (yellow) in this
case happens to have a special sibling (lime)...
It's content is different from |aParentFrame| (pink) hence the assert.

I think the correct algorithm would be to look at the parent of
the placeholder and see if that has any next-in-flow/special-sibling
and continue with its first child if any. That is the next in-flow
child that follows after the hint.

	Mats Palmgren (inactive) Assignee
	Comment 3 • 19 years ago

roc, I saw your name in this method, maybe you can review?

The patch uses the parent of the placeholder, not the out-of-flow.

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 19 years ago

Comment on attachment 207917 [details] [diff] [review]
Patch rev. 1

I think this makes sense... we really need to think about making this whole setup simpler.  :(

	Mats Palmgren (inactive) Assignee
	Comment 5 • 19 years ago

Checked in on trunk at 2006-01-15 15:44 PDT.

-> FIXED