Closed Bug 400185 Opened 17 years ago Closed 17 years ago

Crash [@ nsFrameManager::ReResolveStyleContext] with popupgroup, treecols, nativescrollbar and (re)moving things

Categories

(Core :: XUL, defect, P3)

x86
Windows XP
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: martijn.martijn, Assigned: enndeakin)

References

Details

(Keywords: crash, regression, testcase, Whiteboard: [dbaron-1.9:RsCo])

Crash Data

Attachments

(2 files)

Attached file testcase
See testcase, which crashes current trunk build on load.

This regressed between 2007-07-04 and 2007-07-05, so I think a regression of bug 279703.

Maybe the patch for bug 399013 or bug 386642 can fix this?

http://crash-stats.mozilla.com/report/index/d6542138-7ce2-11dc-9848-001a4bd43e5c
0  	nsFrameManager::ReResolveStyleContext(nsPresContext*, nsIFrame*, nsIContent*, nsStyleChangeList*, nsChangeHint)  	 mozilla/layout/base/nsFrameManager.cpp:1075
1 	nsFrameManager::ReResolveStyleContext(nsPresContext*, nsIFrame*, nsIContent*, nsStyleChangeList*, nsChangeHint) 	mozilla/layout/base/nsFrameManager.cpp:1355
2 	nsFrameManager::ReResolveStyleContext(nsPresContext*, nsIFrame*, nsIContent*, nsStyleChangeList*, nsChangeHint) 	mozilla/layout/base/nsFrameManager.cpp:1365
3 	nsFrameManager::ReResolveStyleContext(nsPresContext*, nsIFrame*, nsIContent*, nsStyleChangeList*, nsChangeHint) 	mozilla/layout/base/nsFrameManager.cpp:1365
4 	nsFrameManager::ReResolveStyleContext(nsPresContext*, nsIFrame*, nsIContent*, nsStyleChangeList*, nsChangeHint) 	mozilla/layout/base/nsFrameManager.cpp:1365
5 	nsFrameManager::ReResolveStyleContext(nsPresContext*, nsIFrame*, nsIContent*, nsStyleChangeList*, nsChangeHint) 	mozilla/layout/base/nsFrameManager.cpp:1365
6 	nsFrameManager::ComputeStyleChangeFor(nsIFrame*, nsStyleChangeList*, nsChangeHint) 	mozilla/layout/base/nsFrameManager.cpp:1427
7 	nsCSSFrameConstructor::RestyleElement(nsIContent*, nsIFrame*, nsChangeHint) 	mozilla/layout/base/nsCSSFrameConstructor.cpp:10091
8 	nsCSSFrameConstructor::ProcessOneRestyle(nsIContent*, nsReStyleHint, nsChangeHint) 	mozilla/layout/base/nsCSSFrameConstructor.cpp:13135
9 	nsCSSFrameConstructor::ProcessPendingRestyles() 	mozilla/layout/base/nsCSSFrameConstructor.cpp:13188
10 	PresShell::DoFlushPendingNotifications(mozFlushType, int) 	mozilla/layout/base/nsPresShell.cpp:4443
11 	PresShell::FlushPendingNotifications(mozFlushType) 	mozilla/layout/base/nsPresShell.cpp:4407
12 	nsCSSFrameConstructor::RestyleEvent::Run() 	mozilla/layout/base/nsCSSFrameConstructor.cpp:13244
13 	nsThread::ProcessNextEvent(int, int*) 	mozilla/xpcom/threads/nsThread.cpp:490
14 	NS_ProcessNextEvent_P(nsIThread*, int) 	nsThreadUtils.cpp:227
15 	nsBaseAppShell::Run() 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:154
16 	nsAppStartup::Run() 	mozilla/toolkit/components/startup/src/nsAppStartup.cpp:170
17 	XRE_main 	mozilla/toolkit/xre/nsAppRunner.cpp:3142
18 	main 	mozilla/browser/app/nsBrowserApp.cpp:153
19 	WinMain 	mozilla/browser/app/nsBrowserApp.cpp:166
20 	__tmainCRTStartup 	crtexe.c:589
21 	BaseProcessStart
Flags: blocking1.9?
Neither the patch in bug 399013 or bug 386642 fix this crash.

I get an assertion also:

###!!! ASSERTION: Deleting out of flow without tearing down placeholder relationship; see comments in nsFrame.h: '!(mState & NS_FRAME_OUT_OF_FLOW) || !shell->FrameManager()->GetPlaceholderFrameFor(this)', file /builds/trunk-project/mozilla/layout/generic/nsFrame.cpp, line 487
Maybe the patch in bug 398982 fixes this?
Nope, it still crashes.
Flags: blocking1.9? → blocking1.9+
Whiteboard: [dbaron-1.9:RsCo]
Assignee: nobody → enndeakin
Attachment #293863 - Flags: superreview?(bzbarsky)
Attachment #293863 - Flags: review?(bzbarsky)
So what is the effect of this patch?  Where do the native anonymous popupgroups come from?  What will we do with the non-anonymous ones?
Each document should have one native anonymous popupgroup created by the document frame (nsDocElementBoxFrame). The popupgroup is used as the content node for an nsPopupSetFrame which holds all of the non-menu popups (tooltips, context menus, etc).

There isn't any reason to have more than one popupgroup element. Creating a second one currently causes assertions.

Ideally, we could just get rid of popupgroup and create an anonymous frame directly in some way.
That doesn't answer the last question in comment 5.  What sort of frame do we end up creating for the popupgroup with this patch?

> Ideally, we could just get rid of popupgroup and create an anonymous frame
> directly in some way.

That's doable, sure.
(In reply to comment #7)
> That doesn't answer the last question in comment 5.  What sort of frame do we
> end up creating for the popupgroup with this patch?
> 

It should just fall through and create a boxframe as with any xul tag that isn't recognized, (and that hasn't changed the display property).
Comment on attachment 293863 [details] [diff] [review]
The easiest fix is to just ignore any attempts to use popupgroup directly

Looks ok, then, assuming we never look for ::popupgroup tags anywhere.
Attachment #293863 - Flags: superreview?(bzbarsky)
Attachment #293863 - Flags: superreview+
Attachment #293863 - Flags: review?(bzbarsky)
Attachment #293863 - Flags: review+
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9b3pre) Gecko/2008010104 Minefield/3.0b3pre ID:2008010104 and the testcase. No Crash on testcase - changing bug to verified fixed
Status: RESOLVED → VERIFIED
Crashtest checked in.
Flags: in-testsuite? → in-testsuite+
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: xptoolkit.menus → xptoolkit.widgets
Crash Signature: [@ nsFrameManager::ReResolveStyleContext]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: