57134 - Need the ability to register user specific components and plugins.

Status: RESOLVED DUPLICATE of bug 14923

(Core :: XPCOM, defect, P3)

Description

[Rich Burridge]

[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).

Comment 1

[David Krause]

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

Comment 2

[Rich Burridge]

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.

Comment 3

[Ray Whitmer]

Reassigning to default XPCOM owner.

Comment 4

[Ray Whitmer]

Trying again.

Comment 5

[Ray Whitmer]

Trying again.

Comment 6

[edburns]

Warren, any action on this one?

Comment 7

[[e-mail]]

Can someone set a milestone for this one?

Comment 8

[Asa Dotzler [:asa]]

reasigning warren bugs to default component owners.

Comment 9

[Doug Turner (:dougt)]

reassign all kandrot xpcom bug.

Comment 10

[Doug Turner (:dougt)]

this is a dup of 14923.

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