314931 - Use content-specific DOMCI macros for XSLT in nsLayoutModule.cpp

Status: RESOLVED FIXED

(Core :: XSLT, defect, P3)

Description

[Benjamin Smedberg]

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

Comment 1

[Peter Van der Beken [:peterv]]

Attachment: v1

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 2

[Johnny Stenback (:jst)]

Comment on attachment 202388 [details] [diff] [review]
v1

r+sr=jst

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Boris Zbarsky [:bzbarsky]]

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?

Comment 5

[Boris Zbarsky [:bzbarsky]]

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)

Comment 6

[Peter Van der Beken [:peterv]]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Peter Van der Beken [:peterv]]

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.