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 .

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

Seeing this on Windows as well. OS -> All

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>

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

Thanks for the help, Dean. -> bryner

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

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

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)

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

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.

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

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.

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

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

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.

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

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

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.

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

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.

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

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.

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

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

(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 on attachment 281369 [details] test spam...