41258 - New JS XPCOM components not loaded

Status: RESOLVED INVALID

(Core :: XPCOM, defect, P3)

Description

[Viswanath Ramachandran]

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.

Comment 1

[Mike McCabe]

cc'ing shaver.

Isn't dp, like, gone for a month or so?

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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

[Viswanath Ramachandran]

Attachment: JS XPCOM component

Comment 4

[Viswanath Ramachandran]

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

[leger]

Moving all current open XPCOM and XPCOM Registry bugs to rayw since dp is on 
sabbatical.  rayw is now default assignee for these components.

Comment 6

[Ray Whitmer]

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.

Comment 7

[Warren Harris]

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.

Comment 8

[Ray Whitmer]

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.

Comment 9

[leger]

Adding nsbeta2 keyword per earlier comments in this bug for triage team to 
review.

Comment 10

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Not critical to beta2. 

Comment 11

[Daniel Veditz [:dveditz]]

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

[Ray Whitmer]

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.

Comment 13

[Warren Harris]

Edward: Welcome to xpcom!

Comment 14

[Warren Harris]

Once again... attempting to reassign from Ray to Edward.

Comment 15

[Edward Kandrot]

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.