Writing configuration files to the binary directory has long been frowned upon in unix and unix like operating systems. A facility is needed to only use a user level component.reg If this is implemented, user based plugins and components should be much easier to take care of

Dunno about plugins, I think they're dealt with through a different mechanism, but putting component.reg in the user's profile dir certainly would be an improvement over the current situation and more easily allow a (future) extension to Mozilla where a user can install new (and perhaps updated?) components in their own directory.

Moving to default XPCOM / Component Manager Owner

We are mounting mozilla over NFS from a server which is exporting the directory as read-only. Users therefor cannot run mozilla as it segfaults immediately upon fireup. Is there a default component.reg that can be added to the installation so that server installs don't crash out-of-the-box? I feel that any program which crashes when it's made read-only doesn't have the right to be on our server :). This a major show stopper for the use of mozilla in distributed environments. Can you speed this one up, and if fixed, in what tree can we get the fix?

maarten@belgonet.be you should be able to run regxpcom, which should be relnoted and is the topic of other bugs.

reassigning kandrot bugs.

Dan, could you comment here. I thought that the component.reg file SHOULD be next to the application. is this invalid/wontfix?

We have a global components registry. If you don't like the fact that the current installer creates this file on the file (to handle dynamic installation configuration) you can get an installed version such as the RegHat .rpm's or Beonex which come with a pre-built component.reg Local add-on components with a local registry to describe them are a good idea, so good that several duplicate bugs have been filed on the subject *** This bug has been marked as a duplicate of 14923 ***