Mozilla Firefox should look for plugins in user's application home directory

RESOLVED FIXED

Status

()

Firefox
General
--
enhancement
RESOLVED FIXED
15 years ago
7 years ago

People

(Reporter: cartman, Unassigned)

Tracking

Trunk
x86
All
Points:
---
Bug Flags:
blocking-aviary1.0PR -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-aviary1.0, URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

15 years ago
Phoenix currently doesnt recognize plugins put under  ~/.phoenix/plugins but it
recognizes plugins under  ~/.mozilla/plugins. 
But it should look under ~/.phoenix/plugins not   ~/.mozilla/plugins since
profile directory is ~/.phoenix .

Comment 1

15 years ago
confirmed. bryner, can you help us with this one?
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

15 years ago
Seeing this on Windows as well.  OS -> All
OS: Linux → All

Comment 3

15 years ago
It looks like this is because of this code:

http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsAppFileLocationProvider.cpp#387

It appends DEFAULT_PRODUCT_DIR to the user's directory.  DEFAULT_PRODUCT_DIR is
hard-coded to "Mozilla" for everything except XP_UNIX, for which it's
".mozilla".  I think this should use the application name instead of a
hard-coded value.  For Unix, lowercase the appname and put a "." in front of it.

<aside> Weird.  Phoenix must never call GetDefaultUserProfileRoot(), because
that calls GetProductDirectory() which is where the hardcoded "Mozilla" is used.
</aside>

Comment 4

15 years ago
If I'm right then this file must be branched for Netscape commercial builds,
with the define changed to "Netscape" and ".netscape".

Updated

15 years ago
Summary: Phoenix should look for plugins under ~/.phoenix/plugins → Phoenix should look for plugins in users profile directory

Comment 5

15 years ago
Thanks for the help, Dean. -> bryner
Assignee: blaker → bryner
What's the equivalent of ~/.mozilla on windows?
Or rather, the equivalent of ~/.mozilla/plugins? \Documents and
Settings\[user]\Application Data\Mozilla\plugins ?

Comment 8

15 years ago
I do not think you can have plugins in the user drectory on any Windows. The
plugin directory is:

c:\Program Files\mozilla.prg\Mozilla\Plugins

The actual disk letter and name of "Program Files" depend on the chosen disk of
win installation and language localisation (meaning there is a Windows variable
for that)

Comment 9

15 years ago
Correction:
c:\Program Files\mozilla.org\Mozilla\Plugins
[obviously .org, not .prg !]

Comment 10

15 years ago
bryner: Yep, that's it.  %appdata%\Mozilla\Plugins.  On older versions of
Windows, %appdata% is c:\windows (or winnt)\Profiles\[user].

jacek: Yes you can.

Updated

15 years ago
Severity: normal → enhancement

Comment 11

15 years ago
Asa: enhancement, really?  Shouldn't we be removing reliance on the .mozilla
directory?

Comment 12

15 years ago
Maybe we should certainly stop poking around in mozilla install and profile
files (I tend to think that if there's something already installed there we
should try to use it rather than telling the user to go re-download it). If we
do want to drop support for searching mozilla files then that's a bug. We
currently search the Phoenix install/plugins dir, right? Adding a plugin search
for the Phoenix profile sounds like a feature to me. 

Updated

14 years ago
Summary: Phoenix should look for plugins in users profile directory → Mozilla Firebird should look for plugins in users profile directory

Updated

14 years ago
Depends on: 171561

Comment 13

14 years ago
I think this should be fixed by utilizing --with-user-appdir, added in bug 58327.

Updated

14 years ago
QA Contact: asa

Comment 14

14 years ago
And kindly do not forget that the Profile Manager allows for the user to
select/create her profile in another location entirely!  Better read it from the
product registry.  Hardcoded paths are >>Very Very Bad<<

Comment 15

14 years ago
superbiskit@cox.net: um, this bug has nothing to do with that, in fact that
should work. but if it doesn't then it should be covered in another bug.

conrad: i think we want to add a SetProductDirectory method, or at the very
least make GetProductDirectory virtual so that something could override it.
Summary: Mozilla Firebird should look for plugins in users profile directory → Mozilla Firebird should look for plugins in user's application home directory
If I understand this problem correctly:

We can't have phoenix-or-mozilla-or-netscape configuration options that affect
xpcom.dll, because that's part of the GRE which we want to share between apps.
So --with-user-appdir is out.

We should factor the base code (without appending .mozilla) in
nsAppFileLocationProvider::GetProductDirectory into a directoryservicedef
USER_DIR or somesuch. Then require applications (including seamonkey) to append
".mozilla" or ".firebird" or whatever they wish.

--BDS

Comment 17

14 years ago
I agree with the coarse of action that Benjamin suggested.  This bug is related
to Bug 76015. If that bug were to get resolved then the next thing would be to
change the application string of the plugins directory to match the profile
directory. And then this bug can be resolved.  Its probably more complicated
than I put it but that is my $0.02.
*** Bug 224400 has been marked as a duplicate of this bug. ***
Summary: Mozilla Firebird should look for plugins in user's application home directory → Mozilla Firefox should look for plugins in user's application home directory

Updated

13 years ago
Flags: blocking1.0?

Comment 19

13 years ago
Now the Profile dir changed to %appdata%\Mozilla\Firefox (in Windows).
http://forums.mozillazine.org/viewtopic.php?t=81428

And Firefox searches plugins from %appdata%\Mozilla\Plugins.
-> Fixed?
This is fixed on the aviary 1.0 branch. When I land semi-single-profile on the
trunk, the same fix will happen there.
Flags: blocking1.0?
Whiteboard: fixed-aviary1.0

Comment 21

13 years ago
(In reply to comment #20)
> This is fixed on the aviary 1.0 branch. When I land semi-single-profile on the
> trunk, the same fix will happen there.

Bug 239929 is FIXED, how about this bug?
Using the branch build from 20040909, the automatic plugin installer puts
plugins in ~/.firefox/plugins, but firefox most definitely does *not* load
plugins from this directory (for me, at least). Can anybody else confirm this?
Doron, where are plugins being installed? They should be in
~/.mozilla/firefox/plugins I think, ~/.firefox is obsolete and unused. But we
really need a better solution in general, because we want to share plugins
across all gecko-based apps. Maybe we should hardcode ~/.mozilla/plugins for all
apps?
Flags: blocking-aviary1.0PR?
My flash xpi puts them in .mozilla/plugins and firefox aviary findsthem fine, as
does seamonkey.
You also want to have xpinstall's getFolder("plugins") return that dir,
currently I am doing a hack and doing getFolder("Profile", "../../plugins") on
linux.

Comment 26

13 years ago
> Maybe we should hardcode ~/.mozilla/plugins for all apps?

Yes, this sounds good to me.  Plugin vendors already know about this location,
so it sounds like the right choice to me.

Comment 27

13 years ago
bit confused by the fixed-aviary1.0 keyword on this bug.  is it fixed on the branch?

think we have run out of time for PR if not and would need to consider this for
final.
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
(In reply to comment #25)
> You also want to have xpinstall's getFolder("plugins") return that dir,
> currently I am doing a hack and doing getFolder("Profile", "../../plugins") on
> linux.

That's definitely wrong for me: for some reason, possibly because I used a
previous version of Firefox, my profile is in $HOME/.firefox, not
$HOME/.mozilla/firefox .
Assignee: bryner → nobody
QA Contact: general
Version: unspecified → Trunk

Comment 29

11 years ago
This is fixed, no? (With the solution that ~/.mozilla/plugins is used.)

Comment 30

10 years ago
(In reply to comment #29)
> This is fixed, no? (With the solution that ~/.mozilla/plugins is used.)
 
I think so, too.
This bug can be fixed.

Comment 31

10 years ago
Created attachment 281369 [details]
test

Comment 32

10 years ago
Comment on attachment 281369 [details]
test

spam...
Attachment #281369 - Attachment is obsolete: true
Attachment #281369 - Attachment is patch: false

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.