See testcase, which crashes current trunk build on load. It doesn't crash in 1.9.1 builds. This regressed between 2009-03-12 and 2009-03-16: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-03-12+04%3A00%3A00&enddate=2009-03-16+09%3A00%3A00 I can look for a more narrow regression range tomorrow, if wanted. Perhaps this is a regression from bug 482889? http://crash-stats.mozilla.com/report/index/e3e28f87-aecf-4ef9-a69c-cfd3b2090528?p=1 0 xul.dll nsIContent::Tag obj-firefox/dist/include/nsIContent.h:220 1 xul.dll xul.dll@0x3c6810 2 xul.dll nsCSSFrameConstructor::ConstructFrameFromItemInternal layout/base/nsCSSFrameConstructor.cpp:3973 3 xul.dll nsCSSFrameConstructor::ContentAppended layout/base/nsCSSFrameConstructor.cpp:6241 4 xul.dll PresShell::ContentAppended layout/base/nsPresShell.cpp:5032 5 xul.dll nsNodeUtils::ContentAppended content/base/src/nsNodeUtils.cpp:120 6 xul.dll nsContentSink::NotifyAppend content/base/src/nsContentSink.cpp:1351 7 xul.dll SinkContext::FlushTags content/html/document/src/nsHTMLContentSink.cpp:1383

Yeah, a regression from bug 482889 part 3. Specifically the part that changed the "item needs block parent" detection in the frame constructor. The issue here is that we think we have such an item (because the <br> is flagged as a line participant), but the frames that get created don't need a block parent (because the <br> ends up out of flow). We could probably fix this by null-checking, because it'll never be wrong the other way, but it's not that hard to just get the line participant count right, I think.

Pushed http://hg.mozilla.org/mozilla-central/rev/b8a7fe28d1bf