264093 - Combine chrome registry and protocol handler on one object

Status: RESOLVED WONTFIX

(Toolkit :: Startup and Profile System, defect, P3)

Description

[Benjamin Smedberg]

I can get rid of some overhead and a pesky static var by combining
nsChromeRegistry and nsChromeProtocolHandler on one object. I also solved the
problems with reentrant GS of the chrome registry during first-startup.

Comment 1

[Benjamin Smedberg]

Attachment: combine nsChromeRegistry and nsChromeProtocolHandler

Comment 2

[Darin Fisher]

Comment on attachment 161904 [details] [diff] [review]
combine nsChromeRegistry and nsChromeProtocolHandler

>Index: nsChromeFactory.cpp

>-    { "Chrome Protocol Handler", 
>+    { "Chrome Registry",

why this change?  is the class name bound to the ClassID or ContractID?


r=darin

Comment 3

[Benjamin Smedberg]

Fixed on trunk. No need to land this on any branches, 'tis just minor code
refactoring.

Comment 4

[Benjamin Smedberg]

Lalala, this appears to have caused leaking of domwindows->the world... I'm
going to look at the startup sequencing.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

so, are you sure that with the component registered under 2 contractids, you
still have only one of them? it seems to me that the service manager will create
one instance per contractid, unless I'm misreading the code

Comment 6

[Benjamin Smedberg]

Yes. The hashtables do contractid -> nsFactoryEntry (which is CID-keyed).

http://lxr.mozilla.org/mozilla/source/xpcom/components/nsComponentManager.h#311

Registering multiple contractids for a service happens all over the place.

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

ah, great. thanks.

Comment 8

[Benjamin Smedberg]

This sounds like more trouble than it's worth at this point.