Testcase is in the URL field. There should only be one letter "c" around, not two. The problem is that the inside bullet means the float's placeholder is not the first thing on the line. Due to something akin to bug 50630, I would guess, we push the float down below the current line. This means we reflow the line _before_ we reflow the float. In particular, we reflow the nsContinuingTextFrame for the text that follows the first-letter _before_ we reflow the nsTextFrame in the nsFirstLetterFrame. The continuing text frame sees that its prev in flow has 0 length (which it does, since it hasn't been reflown yet), and uses 0 for its content offset, hence the rendering bug. Not quite sure what to do here past trying to reflow things in the right order...

WFM with Mac trunk, I think.

I still see this in a build from this morning. Note that you may have to reload to see the bug, for reasons that are not clear to me.

Is this still an issue in current trunk build?

That's a really good question. The new textframe landing broke this testcase completely (only the 'c' showed up), and then the landing of bug 385270 refixed it, and now the original rendering problem seems to be gone. That makes some sense: bug 385270 messed with these offsets. roc, did the offset changes really fix this, or is it just happening to work in this particular testcase by accident, with the basic underlying problem described in comment 0 still present?

Unfortunately, I think the latter. What's happening now, I think, is that the continuation textframe on the first line is taking all the text "click me". Then we reflow the first-in-flow and it takes the first character and leaves the rest in its continuation. So we end up looking right.

That doesn't seem like an unreasonable fix for this bug, in some ways. The real issue here was that the prev-in-flow's content length didn't match the next-in-flows start offset, right? With the new setup that's impossible, so we'll never get content duplication or missing content. And if the first-in-flow will get the right content no matter what order we reflow in... we might be ok.

Right, the new text frame offset setup makes duplication or missing content impossible (yay!). There's still a bug though, for example, the continuation frame might break incorrectly because it thinks it has all the text. A text frame whose offset gets changed by its prev-in-flow needs to be reflowed again eventually. We could maybe fix this by arranging for the continuation to be reflowed again via a post-layout callback or something, but frankly I don't want to bother with that for 1.9, or possibly ever...

This testcase shows the underlying bug persisting. There is a gap between "me" and "!" because the frame's size was computed to include the "c".

Could we reflow floats when we hit their placeholder, possibly? Or is the problem that we need to know their vertical position to do that?

We need to know their vertical position to get vertical breaking right, at least.

Perhaps we could determine the right content offset for the end of the first-letter stuff at frame construction time? It's not reflow-dependant... Then mark this continuation chain as fixed instead of flowable? In fact, there's a comment somewhat to this effect right above FindFirstLetterRange().

Yeah, that's the way to go.