Now that transformiix is built in to layout, it can use the content-specific DOMCI macros in nsLayoutModule. From bug 304494 comment 16.

We didn't have a way to make classes internal to content constructable, so I've added a small array to map from DOMClassInfo ID to contract ID.

Comment on attachment 202388 [details] [diff] [review] v1 r+sr=jst

Could this possibly have affected Tp on btek? It went up a bit after this checkin...

With a build from after this checkin I get: ###!!! ASSERTION: Whaaa, JS environment name clash!: 's->mType == nsGlobalNameStruct::eTypeNotInitialized || s->mType == nsGlobalNameStruct::eTypeInterface', file ../../../../mozilla/dom/src/base/nsScriptNameSpaceManager.cpp, line 642 at startup. The stack is: #2 0xb7f18fc4 in NSGlue_Assertion (aStr=0xb69c0f78 "Whaaa, JS environment name clash!", aExpr=0xb69c0f10 "s->mType == nsGlobalNameStruct::eTypeNotInitialized || s->mType == nsGlobalNameStruct::eTypeInterface", aFile=0xb69c0b18 "../../../../mozilla/dom/src/base/nsScriptNameSpaceManager.cpp", aLine=642) at nsDebug.cpp:110 #3 0xb6760baa in nsScriptNameSpaceManager::RegisterExternalClassName (this=0x82e50b8, aClassName=0xbfffe538 "XPathEvaluator", aCID=@0x81f9230) at ../../../../mozilla/dom/src/base/nsScriptNameSpaceManager.cpp:640 #4 0xb673cb4f in nsDOMClassInfo::RegisterExternalClasses () at ../../../../mozilla/dom/src/base/nsDOMClassInfo.cpp:1595 #5 0xb67435fb in nsDOMClassInfo::Init () At this point we have: (gdb) p s->mType $1 = eTypeClassConstructor Any idea what's up here?

I also get the same for: #3 0xb6760baa in nsScriptNameSpaceManager::RegisterExternalClassName (this=0x82e50b8, aClassName=0xbfffe538 "XPathException", aCID=@0x81f9230) #3 0xb6760baa in nsScriptNameSpaceManager::RegisterExternalClassName (this=0x82e50b8, aClassName=0xbfffe538 "XPathNSResolver", aCID=@0x81f9230) #3 0xb6760baa in nsScriptNameSpaceManager::RegisterExternalClassName (this=0x82e50b8, aClassName=0xbfffe538 "XPathResult", aCID=@0x81f9230) #3 0xb6760baa in nsScriptNameSpaceManager::RegisterExternalClassName (this=0x82e50b8, aClassName=0xbfffe538 "XSLTProcessor", aCID=@0x81f9230)

Not sure how this could affect Tp. If it does it should actually cause it to go down a bit :-/. The assertions you're seeing are probably coming from stale entries in the category for external classes (they became internal with this patch). I'm not sure what we can/should do to get rid of those. Though throwing away the component registry should clear the catgeories and solve it for you, iirc.

I removed components/compreg.dat. Doesn't help -- the assertions are still there. Or did you mean something else when you said "component registry"?

Anyone who sees the asserts, remove the stale transformiix lib if you have one in your components directory (it's now integrated into the layout lib) and blow away the component registry.