See bug 240933 comment 9 and bug 240933 comment 10. The following are the issues I see: 1) I'm not sure we set break types on lines appropriately based on \n in preformatted content. At least part of the problem is that changing the white-space handling just does a reflow and I believe break types survive across reflows, right? If so, we'd need to deal with that. In any case, we return this stuff correctly from nsTextFrame::Reflow, so at least some of this already works. If we had this, working we could use it to optimize dirtying of lines when content is changed while editing. 2) The check for BRFrame in nsBlockFrame::AddFrames should actually check whether the prevsibling would cause a break-after, not check for a BRFrame. 3) It looks like we already call SetLineEndsInBR from nsTextFrame::Reflow, so that should be ok (though perhaps we should rename this or clarify how it interacts with the break-after stuff, or something?)

I can write some testcases if we need to test things, btw.

We could easily make changes to 'white-space' cause a reframe.

Does the reframe clear out info on lines somehow, then? If the info is not stored between reflows, there's nothing to worry about, it seems...

What information are you talking about, exactly? On line boxes, SetLineBreakBefore/After is only about clearance, so not relevant here. SetLineWrapped gets recomputed every time we reflow the line.

Ah. I didn't realize the line break thing was just for clearance. I really wish we had more docs in nsLineBox.h.... ;) I guess the only relevant part then is the LineEndsInBR() thing, and that's recomputed each time we reflow the line too.

The <br> testcase is actually slower. This has been happy ever since bug 229052 added that SetLineEndsInBR() call to nsTextFrame::Reflow. So only item 2 is left, really. Should be easy to fix.

Fixed on trunk.