48849 - MyService shouldn't be loaded by the browser if it isn't used.

Status: VERIFIED DUPLICATE of bug 66358

(SeaMonkey :: Build Config, defect, P3)

Description

[Daniel Bratell]

Why is MyService from xpcom/tests/services included in the browser and why is it 
loaded at startup? 

Observed on a current (2000-08-13) optimized build on Windows 2000. 

If it's just a test it should be easy to remove it. If it's not a test it 
shouldn't live in a directory named test and in neither case if should be loaded 
at startup since it isn't used.

Comment 1

[Ray Whitmer]

From what I am able to tell thus far, the dependency checking / storing of 
autoregistration is not working.  MyService.dll is being loaded again, because 
it is being registered again by autoregistration.

Comment 2

[Ray Whitmer]

This is fairly normal behavior.  MyService lacks the proper symbols it requires 
to autoregister, so as a result, every time autoregistration occurs, the attempt 
is made again to register it, but since it fails, it is never recorded in the 
component registry.

We might change the behavior in a future rewrite to make an entry for errored 
registrations so that the reregistration is not attempted, but it is not clear 
to me that this is a bug right now.

This is just a packaging problem.  Package a DLL in the components directory 
which is not a real component, and you will get this reregistration behavior.  
If you don't like it, then don't put a bad DLL in the components directory.

Comment 3

[Ray Whitmer]

It is not clear what the filer of the bug expected to happen here, remove 
MyComponent from the source tree, remove it from the make file, remove it from 
some installation, etc.  I do not know where this goes.  I am removing nsbeta3, 
because at most it is a packaging problem.  Anyone responsible for packaging a 
specific version of a browser should immediately see that it is not needed.

Comment 4

[Daniel Bratell]

What I want is it removed in such a way that it's not loaded when starting 
Mozilla. Loading it takes time and memory and it's not used. It's only a 
sample (I think), so it's a bug that it's loaded. If this is a packaging 
issue, I'll reassign it to Build Config and renominate it as nsbeta3 to allow a 
Netscape engineer to spend the minutes necessary to remove the reference to it 
from the right places. I'm sorry I don't know what these places are.

Comment 5

[Jon Granrose]

reassign to leaf since he hacks win32.

I suspect this is due to the tarball picking up cruft from the dist directory 
from us not having a mozilla win32 installer.

leaf - would it be possible to have the mozilla win23 tarball be all the 
component directories from a mozilla pkgcp zipped into one file?  so you do the 
pkgcp for mozilla, then create an empty zip file, and go into each component 
directory and zip append the files in that component into the main zip file.  I 
know you can append to zip files on unix, but does win32 let you do that?

Comment 6

[Daniel (Leaf) Nunes]

we so can do this. PLUS ME! PLUS ME!

Comment 7

[Jon Granrose]

setting to 0.91.  I think leaf has another bug that started differently but has
the same end result (deliver a stripped down tarball), so one them should be a dup.

Comment 8

[Jon Granrose]

duplicate of 66358 - once we have a non-installer tarball built from the
packages-* files, this problem will go away.

*** This bug has been marked as a duplicate of 66358 ***

Comment 9

[Jon Granrose]

verified.