[There might be more history then you care to read about, in which case I apologise, but I wanted to convey the complete reasoning behind this proposal]. We at Sun will need to distribute Netscape 6 (PR3 and FCS) internally via /usr/dist, a read-only software distribution hierarchy. There are about 40-50 different sub-domains using at Sun (.Eng, .Corp, .EBay ...) and we will need to have a version of Netscape that can read the Proxy Automatic Configuration (PAC) files that go with each of those domains. There is a bug in Bugzilla for exactly this problem; 53080: http://bugzilla.mozilla.org/show_bug.cgi?id=53080 For our PR2 internal distribution, we redirected users to an internal web page which described how to set the proxies manually. For our PR3 distribution, the Mozilla/Netscape6 code has been fixed so that is correctly handles a component in the .../components directory that includes the findProxyForURL() function. Our goal here was to provide a special version of that function which would basically be the concatentation of all the .pac files we have for the 40-50 domains. After talking to ENS (our internal support Sun-wide support people), it looks like this approach won't work. Some of these .pac files have specific tests (looking for certain subnets), but some also include an "else" clause. We were hoping to get more information from ENS, like the full list of subnets used in each domain. ENS tell me that for some domains, they haven't even properly setup their internal nets to use official subnet numbers. A real mess. An attachment has been added to 53080 that basically allows file:/ and http:// URL's to be used for .pac files, but part of the fix involves copying that PAC file information to the .../components directory. For /usr/dist, this just won't work as this directory hierarchy is mounted read-only. I'm proposing a slightly different approach, that actually would be more generally useful than just solving the PAC file problem we have. It would allow each individually user to have their own components directory (and maybe also their own plugins directory). I suggest that Mozilla should be modified to: * read and register in all the components in the .../components directory (as it currently does). * check to see if there is a "components" directory under the user's ~/.mozilla directory. If there is, then it should read and register any components found there (replacing any existing components with the same name, with the new user specific version). This would allow us to specify a PAC file that is specific for a user in any domain. It would also allow the user to register any new components of their own. A similar approach could be taken for the .../plugins directory as well, allowing an individual user to register their own plugins when Netscape 6 was either installed on their enterprise system as root, and/or in a read-only directory. This approach is consistent with the way config files are normally read and used on Unix systems. This might be something that is only of interest to the Solaris platform, in which case we can surrond the appropriate code in Mozilla with #ifdef SOLARIS, but it might also be of interest to other platforms such as Linux). It would solve some of the problems describes in 41057).

Isn't this bug a dup of 14923 "Local components tracking bug" or am I misreading something?

If we were to implement the fully proposed scenerio, then yes it would be a dup of 14923. 14923 also tracks chrome chanfges too. I've opened this bug as a placeholder to fix the PAC problems with trying to put Netscape 6 in our /usr/dist read-only directory hierarchy. If the full solution is approved (and I seriously doubt that because 14923 has been open for a long time), then that bug should also be referenced.

Reassigning to default XPCOM owner.

Trying again.

Trying again.

Warren, any action on this one?

Can someone set a milestone for this one?

reasigning warren bugs to default component owners.

reassign all kandrot xpcom bug.

this is a dup of 14923. *** This bug has been marked as a duplicate of 14923 ***