New JS XPCOM components not loaded




18 years ago
17 years ago


(Reporter: Viswanath Ramachandran, Assigned: Edward Kandrot)


Windows NT

Firefox Tracking Flags

(Not tracked)



(1 attachment)



18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (WinNT; U)
BuildID:    2000060108

 If new JS XPCOM components are copied to the components area, they DO NOT get 
loaded on restarting mozilla. You have to rmove component.reg for them to be 

Reproducible: Always
Steps to Reproduce:
1.Install a mozilla build and start it once so that component.reg is created.
2.Quit mozilla.
3. Now add a new JS XPCOM component into the components directory (just copy it 
4. Restart mozilla.

Actual Results:  The new JS XPCOM component will NOT be loaded. You have to 
delete component.reg and start mozilla for it to find the component. 

Expected Results:  I expect that the JS XPCOM loader will notice the new 
component and load it. 

It should be  nsbeta2+ because if someone installed only the browser and later 
updates to also install AIM/NIM, AIM/NIM will not work as expected as it uses JS 
XPCOM components. 

Also things like smartupdate that introduce a new JS XPCOM component will not 
work as expected.

I am not sure if this happens with C++ components (dlls) also - even though I 
think not as they are more extensively used and so someone should have noticed.

Comment 1

18 years ago
cc'ing shaver.

Isn't dp, like, gone for a month or so?
Summary: New JS XPCOM components not loaded → New JS XPCOM components not loaded
As far as I know, depending on autoreg is poor form: it's going to go away -- if
it hasn't already, in release builds -- and you should be using either the
XPInstall engine or regxpcom to register your goodies.

Can you verify that this is a JS-specific issue (try building in xpcom/sample to
create a new C++ component, and look for registration messages), and then tell
us more about your build (Mozilla nightly, self-compiled, debug/release, etc.)?


Comment 3

18 years ago
Created attachment 9478 [details]
JS XPCOM component

Comment 4

18 years ago
Sorry didnt update correctly last time. I will dig a bit more to narrow it down.  

I saw it on a commercial nightly release/optimized build. Adding the JS 
component previously attached to that build (as described) did not result in its 
being loaded the next time mozilla was started. I expect this to also happen in 
mozilla optimized. Thanks, Vishy

Comment 5

18 years ago
Moving all current open XPCOM and XPCOM Registry bugs to rayw since dp is on 
sabbatical.  rayw is now default assignee for these components.
Assignee: dp → rayw

Comment 6

18 years ago
My proposal "Registering XPCOM Components" intends to establish autoregistration 
as the preferred way to do things.  My personal feeling is that a system that 
relies on manual registration  is inferior to one that can easily be 
reconfigured via a classpath.  I think a number of people have bought off on 

When run with no arguments, regxpcom seems to simply be a good way to 

I have never used XPInstall before, probably because I never ran the commercial 
build.  Does it need to manually register everything?  This is an issue that 
needs to be straitened out now.

Comment 7

18 years ago
I think the process for discovering new js components should be the same as for 
discovering new native components... and I think that process should not be 
automatic (as it is now for debug builds -- autoregistration). There should be 
an explicit installation step for release builds.

See related bug 43393 about xap files.
Target Milestone: --- → M18

Comment 8

18 years ago
I agree that there is a step to be performed at installation time.

Shoould the step be adding things to the front of a component path or adding to 
a registry, meaning that if the registry gets hosed, you have to reinstall 

I suspect that the current APIs used at install time could simply to add a 
component to the component path and invoke autoregistration.

If someone is currently content with the MS model requiring reinstallations of 
products, and producing unfixable states, then they should be prepared to take 
the heat and grief.  I am not prepared to take that.

Comment 9

18 years ago
Adding nsbeta2 keyword per earlier comments in this bug for triage team to 
Keywords: nsbeta2

Comment 10

18 years ago
Putting on [nsbeta2-] radar. Not critical to beta2. 
Whiteboard: [nsbeta2-]
This bug describes the state as currently designed. AutoRegistration is not run 
everytime in release builds because of the startup performance costs coupled 
with the extreme unlikelyness of finding new things.

AutoReg is performed
 - always in debug builds
 - if component.reg is missing
 - after an XPInstall
 - if the regxpcom utility is run
 - if mozilla is launched with the "-installer" command-line argument

This utility is currently shipped with Windows and Unix builds, but appears not 
to be in the Macintosh version.

Comment 12

18 years ago
Per the prior comments, I believe this functionality is currently working as 
designed, and it is not clear what alternate behavior, if any, would be desired 

The bug does not say that the component does not become visible after xpinstall. 

If there are no other comments here, I will close the bug.


17 years ago
Target Milestone: M18 → M20

Comment 13

17 years ago
Edward: Welcome to xpcom!
QA Contact: leger → rayw
Target Milestone: M20 → mozilla1.0

Comment 14

17 years ago
Once again... attempting to reassign from Ray to Edward.
Assignee: rayw → kandrot

Comment 15

17 years ago
rayw asked for comments on this on 2000-08-31 or he would close this bug.  
There were no further comments, so I will close this bug.
Last Resolved: 17 years ago
Keywords: nsbeta2
Resolution: --- → INVALID
Whiteboard: [nsbeta2-]
You need to log in before you can comment on or make changes to this bug.