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)
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
Comment 1•6 years ago
|
||
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.
Description
•