412449 - Add standard install locations for OSX

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, enhancement)

Description

[Dave Townsend [:mossop]]

Bug 311008 added some standard install locations for Linux. We should add matching directories for windows and OSX.

Comment 1

[Benjamin Smedberg]

FWIW, I disagree that we should add these on Windows... Windows typically doesn't use the concept of well-known filesystem locations, in preference for the registry, which is easier for Windows admins to lock down.

Comment 2

[Dave Townsend [:mossop]]

I would be fine with that, though Mark seemed to prefer having the directories available.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

I won't fight too hard for it, but places like "Common Files" seem appropriate for extensions. The registry is easier to lock down, but is harder to "manage" when you compare it to putting files in a folder.

The registry allows extensions to be scattered, while the folder location provides a nice way to keep them together.

Comment 4

[Pavel Penaz]

Please do correct me if I am totally wrong, but isn't there the variable path %AllUsersProfile% under Windows which has been created for this very purpose?

Under Windows XP this points to C:\Documents and Settings\All Users\Application Data\
Under Windows Vista this points to C:\ProgramData

IMHO Mozilla should use this location for storing data common to all users.

Comment 5

[Dave Townsend [:mossop]]

Attachment: patch rev 1

This is basically it, still need to test on windows though.

Comment 6

[Dave Townsend [:mossop]]

Comment on attachment 301914 [details] [diff] [review]
patch rev 1

This adds the following directories as extension install locations in the app-system-local install location.

Windows: C:\Program Files\Common\Mozilla\Extensions\<appid>
OSX: /Library/Application Support/Mozilla/Extensions/<appid>

I've just split out the code dealing with that file key in the xredirprovider into its own method that only exists on the platforms it works for.

In the EM I just removed the linux defines, the code will already handle those directory keys not existing on the dir provider for other platforms so I see no need to complicate the EM with the ifdefs it'd need to work.

Comment 7

[Benjamin Smedberg]

Comment on attachment 301914 [details] [diff] [review]
patch rev 1

Something's wrong about appending 'Mozilla/Extensions' too many times or not enough.

Comment 8

[Dave Townsend [:mossop]]

Attachment: patch rev 2

This should be better

Comment 9

[Benjamin Smedberg]

Comment on attachment 302568 [details] [diff] [review]
patch rev 2

I'm happy to take this for mac. I don't think I want to do magic directories on Windows, so can I get a patch without Windows changes?

Comment 10

[Dave Townsend [:mossop]]

Attachment: sans windows

Same just without the windows magic directories.

Comment 11

[Dave Townsend [:mossop]]

Comment on attachment 307706 [details] [diff] [review]
sans windows

This brings us platform parity on OSX to that on Linux allowing third party applications to easily add extensions to the application without hacking themselves into the profile or app dir.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 307706 [details] [diff] [review]
sans windows

a1.9=beltzner

Comment 13

[Dave Townsend [:mossop]]

Checking in toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--  nsExtensionManager.js.in
new revision: 1.277; previous revision: 1.276
done
Checking in toolkit/xre/nsXREDirProvider.cpp;
/cvsroot/mozilla/toolkit/xre/nsXREDirProvider.cpp,v  <--  nsXREDirProvider.cpp
new revision: 1.68; previous revision: 1.67
done
Checking in toolkit/xre/nsXREDirProvider.h;
/cvsroot/mozilla/toolkit/xre/nsXREDirProvider.h,v  <--  nsXREDirProvider.h
new revision: 1.19; previous revision: 1.18
done

Comment 14

[Eric Shepherd [:sheppy]]

Removing doc-needed; this doc is covered by another bug.