Closed Bug 45699 Opened 24 years ago Closed 22 years ago

plug-in initialization should load plug-ins from user's profile's plugins directory

Categories

(Core Graveyard :: Plug-ins, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: ekrock, Assigned: ccarlen)

References

Details

Attachments

(1 file, 1 obsolete file)

We need to enable the local installation of legacy plug-ins by users on Linux 
who are running a Mozilla-based browser from a shared server directory to which 
they do not have write access.

Navigator 4 enabled this via a local plugins directory in the user's profile. 
Users running Nav4 from a shared server directory could install plug-ins locally 
in their profile's plugins directory, and plug-ins installed in the profile's 
directory took precedence over any conflicting plug-ins in the shared server 
directory.

In Mozilla, there is a plugins directory in the user's profile directory, but 
the plug-in initialization code currently ignores it.
Changing OS to Linux
OS: Windows NT → Linux
Hardware: PC → All
Eric's posting to m.xpcom said this was helpwanted, so I'm adding the keyword.  
av, sorry if you do not need help (and nuke my keyword).

/be
Keywords: helpwanted
Marking FUTURE as Netscape engineering is overburdened. This amounts to an 
enhancement request for enabling distributed installation of plug-ins in 
shared installation environments, and the target for FCS is individual 
consumers. For the first release, we can settle for users having to install 
plug-ins centrally. helpwanted--mozilla community members by all means 
please sign up to lend a hand!
Target Milestone: --- → Future
Severity: normal → enhancement
*** Bug 57796 has been marked as a duplicate of this bug. ***
Keywords: 4xp
Take a look at 54291 (Need Alternative Location to Load Java Plugins)
Bug 66549 (FIXED) sort of does this on Windows.
Keywords: mozilla1.0
*** Bug 78314 has been marked as a duplicate of this bug. ***
*** Bug 82255 has been marked as a duplicate of this bug. ***
I can simulate a fix by adding ~/.mozilla/default/plugins to NS600_PLUGIN_PATH
as per bug 54291. Since this bug is only a problem on unix, seems it could be
easily resolved by having the launcher add the current profile's "plugins"
directory to NS600_PLUGIN_PATH.
That's not a valid solution. Mozilla should read from both it's 
MOZILLA_HOME/plugins directory and the user's directory (located at his/her 
home directory). For example, JRE will install into MOZILLA_HOME and the Null 
Plugin is located there too, just as many other plugins which might attempt to 
install system-wide.
Also that fix won't work because:
1) It can't be assumed that the profile is called 'default'
2) All new profile directories are salted

So the only way would be to do that manually
*** Bug 87270 has been marked as a duplicate of this bug. ***
*** Bug 93821 has been marked as a duplicate of this bug. ***
Removing nsenterprise nomination, adding nsBranch.
Keywords: nsenterprisensBranch
We should minus this one for this round, since it is futured.
Why is this Future/enhancement, when the keywords state that it is 4xp and a
mozilla1.0 issue?

Also note 12 votes and 5 dupes.
I'm sure it's been said that 4xp bugs aren't enhancements so I'll set severity
to normal. I'm marking this nsenterprise as it prevents users on multi user
machines installing their own plugins without root (Admin) access. Setting OS to
all as there's no reason why windows shouldn't have this.
Severity: enhancement → normal
Keywords: nsenterprise
OS: Linux → All
Blocks: 101245
There aren't any comments on this bug since the 17th of
Sept.  Can QA regess against the Netscape commercial builds and determine if
this is still a valid bug?  If so, and we can get fixes/reviews in the next day
or two, please mark as nsbranch+ which will get this on the PDT radar. Else,
mark is as nsbranch-. Also, can someone comment in the bug how serious you think
this is?  PDT is only accepting "stop ship" bugs such as data loss and loss of
major functionality.
not a stop ship
Keywords: nsbranchnsbranch-
*** Bug 102666 has been marked as a duplicate of this bug. ***
marking nsenterprise-; will be reevaluated for nsenterprise in future release.

Keywords: nsenterprise-
Blocks: 107067
Keywords: nsbranch-
This bug is important for the Sun One Webtop plugin.
Often the automatic installation has no permission to write to
MOZILLA_HOME/plugins catalog. The usage of the user's catalog in addition
to the central one would help.
This is probably a dup of:
http://bugzilla.mozilla.org/show_bug.cgi?id=77231
which is looking like it may be fixed by the next milestone. Not marking as dup
quite yet as this is a nice tracking bug with 17 votes!
Depends on: 77231
It's also related to bug 105440 which I'm currently working on. In that bug,
there will be two additional search paths which will be scanned for plugins:
NS_OS_PLUGINS_DIR_LIST - This is a list of dirs to be scanned for plugins which
is defined by the OS. On OS X (a multi-user system), there are two OS defined
plugin dirs of interest: one in the current user's home dir to which they have
write access, and another from which plugins are available to all users of the
OS  but you'd have to have admin access to install. The definition on other
platforms is not as well defined. Suggestions on the members of this list for
other platforms?
NS_APP_PLUGINS_DIR_LIST - This is a list of dirs is defined by the application
(mozilla or an embedding app) It would contain (at least) the "plugins" dir in
the bin dir of the app. This list is overridable by an embedding app for
customization.
What about user specified plugins but outside of the profile scheme.
e.g. ~/.mozilla/plugins
c:\Windows\Application Data\Mozilla\Plugins
etc

This would solve the problem of allowing users to install plugins if they don't
have write permission to the application directory and would mean users wouldn't
have to copy plugins over to each new profile when they create one.

The main focus of this bug is to make it possible for a normal user to install
their own plugins, I think this solution is more preferable.

However, if some people need per profile control, then this could also be
implemented, just seems like an overkill to me.
*** Bug 119204 has been marked as a duplicate of this bug. ***
nominating ...
Keywords: nsenterprise-nsbeta1
FWIW, I'm in complete agreement with comment #25. That is, the goal here is to
allow users without Admin privleges to install plugins. Those plugins would be
available to all mozilla profiles belonging to that OS-level user. That's very
easy to implement and it already is on Mac OSX. Having plugins on a
per-mozilla-profile basis is very difficult and I don't see the value. Maybe the
word "profile" is being used loosely here. Would it be accurate to resummarie
this bug as "Allow users without admin privleges to install plugins?"
How else do we want to scan for plugins?

Should this bug be broken down per OS?
We don't need to change plugin scanning (directly anyway) We just need to fill
in this code:
http://lxr.mozilla.org/mozilla/source/xpcom/io/nsDirectoryService.cpp#1198 for
platforms other than Mac. Since other platforms don't have predefined locations
for these, we'd have to define them ourselves.
I've set target milestone.
Target Milestone: Future → mozilla1.0
A possible workaround is to set the MOZ_PLUGIN_PATH environment variable.
Target Milestone: mozilla1.0 → Future
Target Milestone: Future → mozilla1.0
The MOZ_PLUGIN_PATH environment variable is not documented anywhere. Maybe we should add it to the next release notes?
Don't comment 10 and 11 still apply?
Bug 77231 is fixed now.
Is any issues remains here or this bug can be closed?
over to serge.
Assignee: av → serge
If anyone outside Netscape wants to implement this, we're all for it, but we're
overloaded for our current release branches (for Netscape purposes).  Minusing
per ADT.
Keywords: nsbeta1nsbeta1-
Do I understand it right that what we need here is to implement
nsIDirectoryService::GetFiles for NS_OS_PLUGINS_DIR_LIST property?
Yes, though it's nsIDirectoryServiceProvider::GetFiles. See the link in comment
#30. It's an easy patch if we can decide what the additional directories should be.
Attached patch patch, v0.1 (obsolete) — Splinter Review
Huh, the best way to decide is to blame one's patch, so here we go! :-)))
I desided to go with "~/.mozilla/plugins" for user plugin dir.
I'm not sure how to implement emunerator in that case (nsAppDirectoryEnumerator

and nsSystemDirEnumeratorMac not suitable here), so I just used 
existing utils.
Let's the fun begin :-)
Should plugins be per-user (in ~/.mozilla/plugins) or
per-profile (in ~/.mozilla/<profilename>/xxxxxxxx.slt/plugins) ?
I could be convinced either way; is there a "better" choice?
Comment on attachment 71871 [details] [diff] [review]
patch, v0.1

>+#else

This doesn't have to go to the work of getting the service, it *is* the service

>+        nsCOMPtr<nsIProperties>
>+          directoryService(do_GetService(NS_DIRECTORY_SERVICE_CONTRACTID, &rv));
>+        if (NS_FAILED(rv))
>+            return rv;
>+
>+        nsCOMPtr<nsILocalFile> file;

NS_APP_USER_PROFILES_ROOT_DIR is ~.mozilla on Unix, but <Application
Data>Mozilla\Profiles on Windows. Might as well keep it consistent and use the
top level of that dir for all.

>+        rv = directoryService->Get(NS_APP_USER_PROFILES_ROOT_DIR, NS_GET_IID(nsIFile), getter_AddRefs(file));
>+        if (NS_FAILED(rv))
>+            return rv;
>+        file->AppendRelativePath(USER_PLUGIN_DIR);
>+        if (NS_FAILED(rv))
>+            return rv;
>+
Attached patch alternate patchSplinter Review
This patch is a bit simpler because it makes uses of the code in
nsAppFileLocationProvider. Since this additional plugin dir is in ~/.mozilla
(and the equivalent on Windows), it's in the domain of the app, not the OS, so
it makes more sense to add it to NS_APP_PLUGINS_DIR_LIST instead of
NS_OS_PLUGINS_DIR_LIST. If this directory was standard to the OS, or somewhere
like ~/plugins or C:\Program Files\Plugins, it would be in the OS domain in
terms of directory service providers.
I believed you that is should be in nsDirectoryService ;-)
Well, at least we have a patch now, so my job is done
Nice!

> Should plugins be per-user (in ~/.mozilla/plugins) or
> per-profile (in ~/.mozilla/<profilename>/xxxxxxxx.slt/plugins) ?

We scan for plugins before a "mozilla" profile is choosen so I think it'd be
quite a bit more work to implement that. And then how would that work with
dynamic profile switching, if we ever go there? Maybe we should have a sperate
RFE bug?

> And then how would that work with dynamic profile switching,

As I said before, it would be a lot of work, and to what gain?

> if we ever go there?

We do go there. It's implemented and embedding clients which use plugins are
using it.
Comment on attachment 71874 [details] [diff] [review]
alternate patch

works good for me on Windows r=peterl
Attachment #71874 - Flags: review+
I just tried this patch on Linux with good result. I created the java link from
within ~/.mozilla/plugins and it worked just fine.
Yes, it looks good.
Nominating and  reassign to Conrad.
Conrad, one question, do we have a release note on env var MOZ_PLUGIN_PATH
mozilla/ xpcom/ io/ nsAppFileLocationProvider.cpp (1.32) 
189                  {
190                      const char *pathVar = PR_GetEnv("MOZ_PLUGIN_PATH");
which actually cannot has a list of dirs with path separators?
Or do we have a bug on this?
Assignee: serge → ccarlen
Keywords: nsbeta1-nsbeta1
Attachment #71871 - Attachment is obsolete: true
Keywords: patch
nominating to nsbeta1+ as per adt triage.  patch already exists.
Keywords: helpwanted, nsbeta1nsbeta1+
Comment on attachment 71874 [details] [diff] [review]
alternate patch

a=asa (on behalf of drivers) for checkin to 0.9.9 and the  Mozilla trunk.
Attachment #71874 - Flags: approval+
Argh, I was at Mozilla Developer Day at CMU (without net access) when the
reviews and approval came in. Will check in ASAP.
Status: NEW → ASSIGNED
So this bug missed the 0.9.9 train? Sad.
Not yet it hasn't, but it will soon.  Conrad: what's the scoop?
> Conrad: what's the scoop?

I'll put down the other things I've been trying to finish 'til this is in. 
Checked into branch and trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
yes, plugins do get picked up on linux from under '.mozilla/pluugins' folder. 
verif on 0311 trunk on redhat 7.1
Status: RESOLVED → VERIFIED
Is this bug the reason we need to re-install Flash plugin with each new version
of Firefox? 
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: