Closed Bug 186667 Opened 23 years ago Closed 6 years ago

if a required overlay fails to load, it may trigger ASSERTION: something's on the context stack already: 'mContextStack.Depth() == 0'

Categories

(Core :: XUL, defect, P5)

x86
Windows 2000
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: timeless, Assigned: timeless)

References

()

Details

(Keywords: assertion)

cvs build from sunday afternoon, i don't think i have patches to xul, i do have one patch to trees and some patches to xbl and i was testing a patch to editor core by opening editor composer. It turns out that I have some _bad_ patches to editor's xul, which cause output like this: Error reading file jar:resource:///chrome/comm.jar!/content/editor/menus.xul *** Failed to load overlay chrome://editor/content/menus.xul The reason for that is a silly change: Index: editor.xul =================================================================== RCS file: /cvsroot/mozilla/editor/ui/composer/content/editor.xul,v retrieving revision 1.144 diff -u -r1.144 editor.xul @@ -35,0 +35,1 @@ +<?xul-overlay href="chrome://editor/content/menus.xul"?> and the lack of a corresponding packaging change for menus.xul so loading that url returns an error. anyway, the console output for the assertion is: ###!!! ASSERTION: something's on the context stack already: 'mContextStack.Depth() == 0', file i:/build/mozilla/content/xul/document/src/nsXULDocument.cpp, line 5288 Break: at file i:/build/mozilla/content/xul/document/src/nsXULDocument.cpp, line 5288 NTDLL! 77f9f9df() nsDebug::Assertion(const char * 0x04392a54, const char * 0x04392a38, const char * 0x043929fc, int 5288) line 280 + 13 bytes nsXULDocument::PrepareToWalk() line 5288 + 47 bytes nsXULDocument::EndLoad(nsXULDocument * const 0x105aed30) line 1726 + 8 bytes XULContentSinkImpl::DidBuildModel(XULContentSinkImpl * const 0x109b9bf8, int 0) line 485 nsExpatDriver::DidBuildModel(nsExpatDriver * const 0x1095eeb8, unsigned int 0, int 1, nsIParser * 0x109b9cc0, nsIContentSink * 0x109b9bf8) line 972 + 23 bytes nsParser::DidBuildModel(unsigned int 0) line 1283 + 41 bytes nsParser::ResumeParse(int 1, int 1, int 1) line 1820 nsParser::ContinueParsing() line 1390 + 19 bytes CSSLoaderImpl::SheetComplete(SheetLoadData * 0x10857a08, int 1) line 1800 CSSLoaderImpl::ParseSheet(nsIUnicharInputStream * 0x109b7af0, SheetLoadData * 0x10857a08, int & 1) line 1733 SheetLoadData::OnStreamComplete(SheetLoadData * const 0x10857a08, nsIUnicharStreamLoader * 0x109b6e00, nsISupports * 0x00000000, unsigned int 0, nsIUnicharInputStream * 0x109b7af0) line 1124 + 23 bytes nsUnicharStreamLoader::OnStopRequest(nsUnicharStreamLoader * const 0x109b6e04, nsIRequest * 0x1098e028, nsISupports * 0x00000000, unsigned int 0) line 187 nsJARChannel::OnStopRequest(nsJARChannel * const 0x1098e02c, nsIRequest * 0x109fd874, nsISupports * 0x00000000, unsigned int 0) line 606 + 49 bytes nsOnStopRequestEvent::HandleEvent() line 213 nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x109cb374) line 116 PL_HandleEvent(PLEvent * 0x109cb374) line 663 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x01033028) line 593 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00d30782, unsigned int 49306, unsigned int 0, long 16986152) line 1379 + 9 bytes USER32! 77e13eb0() USER32! 77e1401a() USER32! 77e13f0f() nsAppShellService::Run(nsAppShellService * const 0x03e0d608) line 472 main1(int 3, char * * 0x002e44c0, nsISupports * 0x002d6f08) line 1543 + 32 bytes main(int 3, char * * 0x002e44c0) line 1904 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e87903() and here are selected portions of mContextStack: - mContextStack {...} |- mTop 0x109beda8 ||- mPrototype 0x109bb930 |||- nsXULPrototypeNode {...} |||| mType eType_Element |||\ mRefCnt 1 ||| mNumChildren 5 |||- mChildren 0x109d2af8 |||\+ 0x0e4cbb70 ||\- mNodeInfo {...} || \- mRawPtr 0x10990db8 || |+ [nsNodeInfo] {...} || \- mInner {...} || |- mName 0x01071230 || |\- [PermanentAtomImpl] {...} || | \- AtomImpl {...} || | |+ nsIAtom {...} || | \- mString 0x0107123c || | \ [0] 111 "o\0v\0e\0r\0l\0a\0y\0\0\0" || \ mNamespaceID 9 || mNumAttributes 2 ||- mAttributes 0x109bba14 ||\- mNodeInfo {...} || \- mRawPtr 0x109bba68 || |+ [nsNodeInfo] {...} || \- mInner {...} || \- mName 0x03df5760 || \- [PermanentAtomImpl] {...} || \- AtomImpl {...} || |+ nsIAtom {...} || \- mString 0x03df576c || \ [0] 105 "i\0d\0\0\0" ||+ mPrefix 0x00000000 || mNamespaceID 0 ||+ mElement 0x00000000 || mIndex 2 |\+ mNext 0x00000000 \ mDepth 1 I think ResumeWalk is buggy. else { // We're in the "first ply" of an overlay: the // "hookup" nodes. Create an 'overlay' element so // that we can continue to build content, and // enter a forward reference so we can hook it up // later. rv = CreateOverlayElement(protoele, getter_AddRefs(child)); if (NS_FAILED(rv)) return rv; } I'm 99% certain CreateOverlayElement failed, and I believe that when it fails, we should pop the context before we return. I'm filing this now because i need to use this browser and that browser for stuff, i'll attach a patch after i verify that i'm right about the failure.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets

XUL overlays were removed in bug 1426763.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.