Some upstream code assumes that the executable path from the path service is

standardized, but NSBundle makes not such promise, so we standardize it
ourselves.

While here, remove the app data dir support since it seems the installer and
windows sandbox are the only things that need it.  Moved that code upstream
to the chrome paths...

Directly handle the user data dir w/in the chrome path service call back, return
different things for chrome vs. chromium.

Review URL: http://codereview.chromium.org/48089

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11910 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 4 insertions, 15 deletions

diff --git a/base/base_paths_mac.mm b/base/base_paths_mac.mm
index 394a588..cd0287c 100644
--- a/base/base_paths_mac.mm
+++ b/base/base_paths_mac.mm
@@ -19,21 +19,10 @@ bool PathProviderMac(int key, FilePath* result) {
   switch (key) {
     case base::FILE_EXE:
     case base::FILE_MODULE: {
-      NSString* path = [[NSBundle mainBundle] executablePath];
-      cur = [path fileSystemRepresentation];
-      break;
-    }
-    case base::DIR_APP_DATA:
-    case base::DIR_LOCAL_APP_DATA: {
-      // TODO(erikkay): maybe we should remove one of these for mac?  The local
-      // vs. roaming distinction is fairly Windows-specific.
-      NSArray* dirs = NSSearchPathForDirectoriesInDomains(
-          NSApplicationSupportDirectory, NSUserDomainMask, YES);
-      if (!dirs || [dirs count] == 0)
-        return false;
-      DCHECK([dirs count] == 1);
-      NSString* tail = [[NSString alloc] initWithCString:"Google/Chrome"];
-      NSString* path = [[dirs lastObject] stringByAppendingPathComponent:tail];
+      // Executable path can have relative references ("..") depending on
+      // how the app was launched.
+      NSString* path =
+          [[[NSBundle mainBundle] executablePath] stringByStandardizingPath];
       cur = [path fileSystemRepresentation];
       break;
     }