535483 - Crash [@ nsIFrame::GetPositionIgnoringScrolling] with position:fixed and mathml

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase, which crashes after 50ms on trunk and current Firefox3.5.6 build.

http://crash-stats.mozilla.com/report/index/bp-d65d44d8-d7f0-4d4f-8cec-865e82091216
0  	xul.dll  	nsIFrame::GetPositionIgnoringScrolling  	 layout/generic/nsIFrame.h:787
1 	xul.dll 	nsHTMLReflowState::CalculateHypotheticalBox 	
2 	xul.dll 	nsHTMLReflowState::InitAbsoluteConstraints 	layout/generic/nsHTMLReflowState.cpp:1183
3 	xul.dll 	nsHTMLReflowState::InitResizeFlags 	layout/generic/nsHTMLReflowState.cpp:425
4 	xul.dll 	nsAbsoluteContainingBlock::ReflowAbsoluteFrame 	layout/generic/nsAbsoluteContainingBlock.cpp:443
5 		@0x420d97f

Comment 1

[Mats Palmgren (inactive)]

Attachment: stack + frame tree

cbrs->frame == aContainingBlock
http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsHTMLReflowState.cpp#1105
The frame tree looks reasonable to me at first glance.

Maybe we should simply change the do{}while(x) to a while(x){}

Comment 2

[Mats Palmgren (inactive)]

Attachment: wip1

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Comment on attachment 426434 [details] [diff] [review]
wip1

r=dbaron, although I'm not sure that having the ViewportFrame be a containing block for anything other than fixed pos frames is actually a good idea.  Then again, I think we don't have box frames be containing blocks at all, so that probably wins.

r=dbaron

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Comment on attachment 426434 [details] [diff] [review]
wip1

Actually, I think the real problem here is described in bug 469861, so changing this to review-.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yeah, the patch in bug 469861 fixed this.