Sorry, I'm a little confused right now, what is the code in addChild() that does this? What is happening in your testcase? Thanks!

    } else if (!childrenInline() && (newChild->isFloatingOrOutOfFlowPositioned() || newChild->isInline())) {
        // If we're inserting an inline child but all of our children are blocks, then we have to make sure
        // it is put into an anomyous block box. We try to use an existing anonymous box if possible, otherwise
        // a new one is created and inserted into our list of children in the appropriate position.

You won't believe what happens next! :)

If we have an anonymous block that was initially created to hold a text flex item, and then re-use it and put an abspos inside it... that can't be right? The abspos should end up as a sibling of said anonymous block, not a child. We want two flex items, one for the text and one for the abspos - right?

My test case has flexboxes, each with three items (or at least that's what I think would be the correct behavior). The middle item is absolutely positioned. The first and last item is either an anonymous block with text inside, or a DIV with text inside.

Hmm, I see. Isn't it weird that out-of-flow is treated the same as inline here? I'm not sure what case that is supposed to cover?

It's not so weird for block container layout (LayoutBlockFlow). Out-of-flow objects and floats can be both block and inline children, but if there's an adjacent anonymous block for inline children at the insertion point, reparent into that one, for the sake of consistency.

It's a long story, and I don't even know if I'm able to tell it right. :)

For flexbox, however, I shouldn't think this makes any sense at all.

OK, I see. Yeah... this might need an !isFlexibleBox() check but then this gets even more complicated :(

Yes, but I'm planning on moving everything there that actually is specific to LayoutBlockFlow down to LayoutBlock, which will leave a complexity-vacuum in LayoutBlock::addChild(). :)

Another option is to override addChild() in LayoutFlexibleBox. It should be fairly easy to do when I'm done with the moving-around.

Looking forward to it!

Can't have a complexity vacuum here ;)

Mild complexity vacuum detected in LayoutBlock::addChild(). ;)

https://codereview.chromium.org/1974753002/

Seriously, though, if you want to fix this, maybe add a LayoutFlexibleBox::addChild() override instead?

Yeah, that seems like a good idea. I'll keep it as a low-priority item.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This now works as expected.