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

VERIFIED FIXED in mozilla1.0

Status

()

Core
Plug-ins
P3
normal
VERIFIED FIXED
17 years ago
7 years ago

People

(Reporter: ekrock's old account (dead), Assigned: Conrad Carlen (not reading bugmail))

Tracking

Trunk
mozilla1.0
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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.

Comment 1

17 years ago
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
(Reporter)

Comment 3

17 years ago
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

Updated

17 years ago
Severity: normal → enhancement

Comment 4

17 years ago
*** Bug 57796 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Keywords: 4xp

Comment 5

17 years ago
Take a look at 54291 (Need Alternative Location to Load Java Plugins)

Comment 6

17 years ago
Bug 66549 (FIXED) sort of does this on Windows.

Updated

16 years ago
Keywords: mozilla1.0
*** Bug 78314 has been marked as a duplicate of this bug. ***

Comment 8

16 years ago
*** Bug 82255 has been marked as a duplicate of this bug. ***

Comment 9

16 years ago
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.

Comment 10

16 years ago
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.

Comment 11

16 years ago
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

Comment 12

16 years ago
*** Bug 87270 has been marked as a duplicate of this bug. ***
*** Bug 93821 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Keywords: nsCatFood, nsenterprise

Comment 14

16 years ago
Removing nsenterprise nomination, adding nsBranch.
Keywords: nsenterprise → nsBranch

Comment 15

16 years ago
We should minus this one for this round, since it is futured.

Comment 16

16 years ago
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.

Comment 17

16 years ago
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

Comment 18

16 years ago
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.

Comment 19

16 years ago
not a stop ship
Keywords: nsbranch → nsbranch-
*** Bug 102666 has been marked as a duplicate of this bug. ***

Comment 21

16 years ago
marking nsenterprise-; will be reevaluated for nsenterprise in future release.

Keywords: nsenterprise-

Updated

16 years ago
Blocks: 107067

Updated

16 years ago
Keywords: nsbranch-

Comment 22

16 years ago
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.

Comment 23

16 years ago
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
(Assignee)

Comment 24

16 years ago
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.

Comment 25

16 years ago
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.

Comment 26

16 years ago
*** Bug 119204 has been marked as a duplicate of this bug. ***

Comment 27

16 years ago
nominating ...
Keywords: nsenterprise- → nsbeta1
(Assignee)

Comment 28

16 years ago
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?"

Comment 29

16 years ago
How else do we want to scan for plugins?

Should this bug be broken down per OS?
(Assignee)

Comment 30

16 years ago
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.

Comment 31

16 years ago
I've set target milestone.
Target Milestone: Future → mozilla1.0

Comment 32

16 years ago
A possible workaround is to set the MOZ_PLUGIN_PATH environment variable.
Target Milestone: mozilla1.0 → Future

Updated

16 years ago
Target Milestone: Future → mozilla1.0

Comment 33

16 years ago
The MOZ_PLUGIN_PATH environment variable is not documented anywhere. Maybe we should add it to the next release notes?

Comment 34

16 years ago
Don't comment 10 and 11 still apply?

Comment 35

16 years ago
Bug 77231 is fixed now.
Is any issues remains here or this bug can be closed?

Comment 36

16 years ago
over to serge.
Assignee: av → serge

Comment 37

16 years ago
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: nsbeta1 → nsbeta1-

Comment 38

16 years ago
Do I understand it right that what we need here is to implement
nsIDirectoryService::GetFiles for NS_OS_PLUGINS_DIR_LIST property?
(Assignee)

Comment 39

16 years ago
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.

Comment 40

16 years ago
Created attachment 71871 [details] [diff] [review]
patch, v0.1

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 :-)

Comment 41

16 years ago
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?
(Assignee)

Comment 42

16 years ago
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;
>+
(Assignee)

Comment 43

16 years ago
Created attachment 71874 [details] [diff] [review]
alternate patch

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.

Comment 44

16 years ago
I believed you that is should be in nsDirectoryService ;-)
Well, at least we have a patch now, so my job is done

Comment 45

16 years ago
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?

(Assignee)

Comment 46

16 years ago
> 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 47

16 years ago
Comment on attachment 71874 [details] [diff] [review]
alternate patch

works good for me on Windows r=peterl
Attachment #71874 - Flags: review+

Comment 48

16 years ago
I just tried this patch on Linux with good result. I created the java link from
within ~/.mozilla/plugins and it worked just fine.

Comment 49

16 years ago
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

Updated

16 years ago
Attachment #71871 - Attachment is obsolete: true

Updated

16 years ago
Keywords: patch

Comment 50

16 years ago
nominating to nsbeta1+ as per adt triage.  patch already exists.
Keywords: helpwanted, nsbeta1 → nsbeta1+
Comment on attachment 71874 [details] [diff] [review]
alternate patch

sr=roc+moz
Attachment #71874 - Flags: superreview+

Comment 52

16 years ago
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+
(Assignee)

Comment 53

16 years ago
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

Comment 54

16 years ago
So this bug missed the 0.9.9 train? Sad.
Not yet it hasn't, but it will soon.  Conrad: what's the scoop?
(Assignee)

Comment 56

16 years ago
> Conrad: what's the scoop?

I'll put down the other things I've been trying to finish 'til this is in. 
(Assignee)

Comment 57

16 years ago
Checked into branch and trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 58

16 years ago
yes, plugins do get picked up on linux from under '.mozilla/pluugins' folder. 
verif on 0311 trunk on redhat 7.1
Status: RESOLVED → VERIFIED

Comment 59

12 years ago
Is this bug the reason we need to re-install Flash plugin with each new version
of Firefox? 
You need to log in before you can comment on or make changes to this bug.