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

Status: RESOLVED FIXED

(Firefox :: General, enhancement)

Description

[cartman]

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

[Asa Dotzler [:asa]]

confirmed. bryner, can you help us with this one?

Comment 2

[:deanis74]

Seeing this on Windows as well.  OS -> All

Comment 3

[:deanis74]

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

[:deanis74]

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

Comment 5

[Blake Ross]

Thanks for the help, Dean. -> bryner

Comment 6

[Brian Ryner (not reading)]

What's the equivalent of ~/.mozilla on windows?

Comment 7

[Brian Ryner (not reading)]

Or rather, the equivalent of ~/.mozilla/plugins? \Documents and
Settings\[user]\Application Data\Mozilla\plugins ?

Comment 8

[Jacek Piskozub]

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

[Jacek Piskozub]

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

Comment 10

[:deanis74]

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.

Comment 11

[:deanis74]

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

Comment 12

[Asa Dotzler [:asa]]

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. 

Comment 13

[:deanis74]

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

Comment 14

[David A. Cobb]

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

[timeless]

[e-mail]: 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.

Comment 16

[Benjamin Smedberg]

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

[Ayo]

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.

Comment 18

[Jeff Walden [:Waldo]]

*** Bug 224400 has been marked as a duplicate of this bug. ***

Comment 19

[Anbo Motohiko]

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?

Comment 20

[Benjamin Smedberg]

This is fixed on the aviary 1.0 branch. When I land semi-single-profile on the
trunk, the same fix will happen there.

Comment 21

[Anbo Motohiko]

(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?

Comment 22

[Joe Drew (not getting mail)]

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?

Comment 23

[Benjamin Smedberg]

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?

Comment 24

[Doron Rosenberg (IBM)]

My flash xpi puts them in .mozilla/plugins and firefox aviary findsthem fine, as
does seamonkey.

Comment 25

[Doron Rosenberg (IBM)]

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

[Darin Fisher]

> 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

[chris hofmann]

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.

Comment 28

[Joe Drew (not getting mail)]

(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 .

Comment 29

[Magnus Melin [:mkmelin]]

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

Comment 30

[Hideo Oshima]

(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

[Genoud]

Attachment: test

Comment 32

[Magnus Melin [:mkmelin]]

Comment on attachment 281369 [details]
test

spam...