Closed Bug 432801 Opened 14 years ago Closed 12 years ago

Crash [@ nsRuleNode::GetStylePosition] with xul:menuitem, xul:tooltip, math:sup and position: absolute


(Core :: Layout, defect)

Not set





(Reporter: martijn.martijn, Assigned: mats)



(Keywords: crash, regression, testcase, Whiteboard: [sg:critical?][maybe not critical after bug 475128?])

Crash Data


(2 files)

Attached file testcase
See testcase, which crashes in current trunk build.

This seems to have regressed between 2008-01-10 and 2008-01-11:
I guess a regression from bug 408933.
0  	xul.dll  	nsRuleNode::GetStylePosition  	 mozilla/layout/style/nsStyleStructList.h:87
1 	xul.dll 	nsStyleContext::GetStylePosition 	mozilla/layout/style/nsStyleStructList.h:87
2 	xul.dll 	nsIFrame::GetStylePosition 	nsStyleStructList.h:87
3 	xul.dll 	nsHTMLReflowState::Init 	mozilla/layout/generic/nsHTMLReflowState.cpp:296
4 	xul.dll 	nsHTMLReflowState::nsHTMLReflowState 	mozilla/layout/generic/nsHTMLReflowState.cpp:176
5 	xul.dll 	nsAbsoluteContainingBlock::ReflowAbsoluteFrame 	mozilla/layout/generic/nsAbsoluteContainingBlock.cpp:414
6 		@0x3fffffff
Fix coming up...
Assignee: nobody → mats.palmgren
Group: security
OS: Windows XP → All
Hardware: PC → All
Whiteboard: [sg:critical?]
When calling nsMenuFrame::Append/InsertFrames with a child list that
contains a MenuPopupFrame + one or more children we simply forget to
insert/append the rest of the children:,1218,1241,1251,1211,1245#1200
For the testcase it's the placeholder that get's lost, then we call
nsCSSFrameConstructor::RebuildAllStyleData() which will use the old
style context since we didn't find the placeholder on any child list.

Also, we intended to propagate the debug bit to mPopupFrame there, right?
Attached patch Patch rev. 1Splinter Review
1. call nsBoxFrame::Append/InsertFrames for the remaining frames
2. propagate the debug bit to mPopupFrame

nsBoxFrame will take care of setting the debug bit for the
remaining frames and call FrameNeedsReflow(eTreeChange).
Attachment #320041 - Flags: superreview?(roc)
Attachment #320041 - Flags: review?(roc)
It seems wrong that someone is calling Append/InsertFrames with null aListName with a frame list including the popup frame and expecting the popup frame to be magically moved to the popup list. That seems like a bug in the caller.
Comment on attachment 320041 [details] [diff] [review]
Patch rev. 1

Need a response to comment #4
Attachment #320041 - Flags: superreview?(roc)
Attachment #320041 - Flags: review?(roc)
Still crashes in current trunk build.
Flags: blocking1.9.1?
Flags: blocking1.9.1? → wanted1.9.1+
Still crashes in current trunk build.
Flags: blocking1.9.2?
Can't reproduce the crash, but there sure are some evil assertions
###!!! ASSERTION: style context has old rule node: 'n == mRuleTree', file /mozilla/layout/style/nsStyleSet.cpp, line 181
###!!! ASSERTION: old rule tree still referenced: 'Not Reached', file /home/smaug/mozilla/layout/style/nsStyleSet.cpp, line 947
###!!! ASSERTION: Some objects allocated with AllocateFrame were not freed: 'mFrameCount == 0', file /mozilla/layout/base/nsPresShell.cpp, line 681
Perhaps also related to bug 474377?
Is this still sg:critical after bug 475128 landed?
Whiteboard: [sg:critical?] → [sg:critical?][maybe not critical after bug 475128?]
Flags: blocking1.9.2? → wanted1.9.2+
WFM, no assertions for me on Mac.
Closed: 12 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsRuleNode::GetStylePosition]
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.