495350 - Crash [@ nsIContent::Tag] with display: -moz-inline-box; and br position: fixed

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

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.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed fix

Comment 3

[Boris Zbarsky [:bzbarsky]]

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