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)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.0
People
(Reporter: ekrock, Assigned: ccarlen)
References
Details
Attachments
(1 file, 1 obsolete file)
1.67 KB,
patch
|
peterlubczynski-bugs
:
review+
roc
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
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 2•24 years ago
|
||
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•24 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
Comment 5•24 years ago
|
||
Take a look at 54291 (Need Alternative Location to Load Java Plugins)
Updated•23 years ago
|
Keywords: mozilla1.0
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•23 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•23 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•23 years ago
|
||
*** Bug 87270 has been marked as a duplicate of this bug. ***
Comment 13•23 years ago
|
||
*** Bug 93821 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Keywords: nsCatFood,
nsenterprise
Comment 14•23 years ago
|
||
Removing nsenterprise nomination, adding nsBranch.
Keywords: nsenterprise → nsBranch
Comment 15•23 years ago
|
||
We should minus this one for this round, since it is futured.
Comment 16•23 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•23 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.
Comment 18•23 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 20•23 years ago
|
||
*** Bug 102666 has been marked as a duplicate of this bug. ***
Comment 21•23 years ago
|
||
marking nsenterprise-; will be reevaluated for nsenterprise in future release.
Keywords: nsenterprise-
Comment 22•23 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•23 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•23 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•23 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•23 years ago
|
||
*** Bug 119204 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 28•23 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•23 years ago
|
||
How else do we want to scan for plugins? Should this bug be broken down per OS?
Assignee | ||
Comment 30•23 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 32•23 years ago
|
||
A possible workaround is to set the MOZ_PLUGIN_PATH environment variable.
Target Milestone: mozilla1.0 → Future
Updated•23 years ago
|
Target Milestone: Future → mozilla1.0
Comment 33•23 years ago
|
||
The MOZ_PLUGIN_PATH environment variable is not documented anywhere. Maybe we should add it to the next release notes?
Comment 34•23 years ago
|
||
Don't comment 10 and 11 still apply?
Comment 35•23 years ago
|
||
Bug 77231 is fixed now. Is any issues remains here or this bug can be closed?
Comment 37•23 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.
Comment 38•23 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•23 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•23 years ago
|
||
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•23 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•23 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•23 years ago
|
||
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•23 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•23 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•23 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•23 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•23 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•23 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?
Updated•23 years ago
|
Attachment #71871 -
Attachment is obsolete: true
Comment on attachment 71874 [details] [diff] [review] alternate patch sr=roc+moz
Attachment #71874 -
Flags: superreview+
Comment 52•23 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•23 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•22 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•22 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•22 years ago
|
||
Checked into branch and trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 58•22 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•19 years ago
|
||
Is this bug the reason we need to re-install Flash plugin with each new version of Firefox?
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•