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 found. 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 there). 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.
cc'ing shaver. Isn't dp, like, gone for a month or so?
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.)?
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
Moving all current open XPCOM and XPCOM Registry bugs to rayw since dp is on sabbatical. rayw is now default assignee for these components.
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 this. When run with no arguments, regxpcom seems to simply be a good way to pre-auto-reg. 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.
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.
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 everything? 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.
Adding nsbeta2 keyword per earlier comments in this bug for triage team to review.
Putting on [nsbeta2-] radar. Not critical to beta2.
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.
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 instead. 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.
Edward: Welcome to xpcom!
Once again... attempting to reassign from Ray to Edward.
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.