summaryrefslogtreecommitdiffstats
path: root/chrome/common/chrome_paths_internal.h
Commit message (Collapse)AuthorAgeFilesLines
* Remove the rest of #pragma once in one big CL.ajwong@chromium.org2012-07-111-1/+0
| | | | | | | | | For context see this thread: https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/chromium-dev/RMcVNGjB4II TBR=thakis,pkasting,jam git-svn-id: svn://svn.chromium.org/chrome/trunk/src@146163 0039d316-1c4b-4281-b951-d872f2087c98
* Do not show the EULA if it has already been accepted by the user in another ↵grt@chromium.org2012-06-161-0/+6
| | | | | | | | | | | user data dir. BUG=131033 TEST=install system-level chrome with require_eula in master prefs and eulaaccepted=0 in the ClientState key. nuke all user data dirs (including the metro one). now launch desktop chrome and accept the eula. make chrome the default browser and launch into metro. notice that it works. Review URL: https://chromiumcodereview.appspot.com/10539153 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142576 0039d316-1c4b-4281-b951-d872f2087c98
* Add PathService::Get(chrome::DIR_USER_PICTURES).thestig@chromium.org2012-05-171-0/+3
| | | | | | | | | BUG=none TEST=none Review URL: https://chromiumcodereview.appspot.com/10392094 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@137596 0039d316-1c4b-4281-b951-d872f2087c98
* Make sure only the main browser process and service processes are allowed to ↵pastarmovj@chromium.org2012-05-091-0/+5
| | | | | | | | | | | | | | create the profile directory. This patch lets Chrome start with profile located on a network share on Windows Vista and newer. BUG=120388 TEST=Start Chrome with --user-data-dir pointing to a network share location and try to navigate to a web page. This should not lead to a hang of the renderer. NaCl and NPAPI plugins should run fine too. Review URL: https://chromiumcodereview.appspot.com/10390003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@136020 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 135321 - Make sure only the main browser process and service proceses ↵pastarmovj@chromium.org2012-05-041-5/+0
| | | | | | | | | | | | | | | | | | are allowed to create the profile directory. This patch lets Chrome start with profile located on a network share on Windows Vista and newer. BUG=120388 TEST=Start Chrome with --user-data-dir pointing to a network share location and try to navigate to a web page. This should not lead to a hang of the renderer. Review URL: http://codereview.chromium.org/10306009 TBR=pastarmovj@chromium.org Review URL: https://chromiumcodereview.appspot.com/10382012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@135347 0039d316-1c4b-4281-b951-d872f2087c98
* Make sure only the main browser process and service proceses are allowed to ↵pastarmovj@chromium.org2012-05-041-0/+5
| | | | | | | | | | | | | | | create the profile directory. This patch lets Chrome start with profile located on a network share on Windows Vista and newer. BUG=120388 TEST=Start Chrome with --user-data-dir pointing to a network share location and try to navigate to a web page. This should not lead to a hang of the renderer. Review URL: http://codereview.chromium.org/10306009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@135321 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: Use the same safe downloads logic as Windows. (try 2)thestig@chromium.org2012-04-281-2/+2
| | | | | | | | | | | BUG=none TEST=none First attempt: http://codereview.chromium.org/10241007/ Review URL: http://codereview.chromium.org/10255018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@134438 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 134362 - Linux: Use the same safe downloads logic as Windows.yoz@chromium.org2012-04-271-2/+2
| | | | | | | | | | | | | | Breaks compile on Win Builder 2010. BUG=none TEST=none Review URL: http://codereview.chromium.org/10241007 TBR=thestig@chromium.org Review URL: https://chromiumcodereview.appspot.com/10252016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@134365 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: Use the same safe downloads logic as Windows.thestig@chromium.org2012-04-271-2/+2
| | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/10241007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@134362 0039d316-1c4b-4281-b951-d872f2087c98
* Add external extensions json source in proper mac location.skerner@google.com2011-09-221-0/+3
| | | | | | | | | | | The old path will be deprecated once developers have migrated. BUG=67203 TEST=FileUtilTest.IsPathControledByAdmin Review URL: http://codereview.chromium.org/7718021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@102274 0039d316-1c4b-4281-b951-d872f2087c98
* Use the real Mac browser app's bundle identifier everywhere that a basemark@chromium.org2011-04-221-1/+13
| | | | | | | | | | | | | | | | | | | | | bundle identifier is needed on the Mac. This means that everything will use up using org.chromium.Chromium, com.google.Chrome, or com.google.Chrome.canary when it's important to get the base bundle identifier. .helper and .framework will not be appended. Note, however, that things that run inside the helper and use CFPreferences or NSUserDefaults will continue to write their defaults as org.chromium.Chromium.helper or com.google.Chrome.helper. Mostly this just affects the Flash plug-in's settings for the NSNav open dialog. There is no com.google.Chrome.canary.helper, but that's not expected to be a problem. This change ensures that Chromes, canaries, and Chromiums don't get in each other's way. BUG=79814 TEST=none Review URL: http://codereview.chromium.org/6896003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@82626 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 67201 - Revert 67191 - chrome_paths: refactor and sanitize cache ↵viettrungluu@chromium.org2010-11-241-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | directory handling [Checking to see if this build failures on Windows.] [[Nope. Failure was a flake.]] Previously we had a bunch of logic in profile_impl.cc that computed where the cache directory lives. This change relocates it to chrome_paths.cc. Some background on cache directories. There are two possible places to store cache files: 1) in the user data directory 2) in an OS-specific user cache directory On Windows, we always pick (1). On Mac and Linux, we currently use (2) in some circumstances. This patch changes both Mac and Linux to have the same behavior with respect to (2). The Mac/Linux shared behavior is that if the profile directory is in the standard location for profiles, we put the cache files into a matching directory name in the standard system cache directory (e.g. on Linux if you're using ~/.config/google-chrome, your cache ends up in ~/.cache/google-chrome; on Mac, the directories are ~/Library/Application Support versus ~/Library/Caches). If your user data directory is not in the standard location, we use behavior (1). The semantic changes of this patch should be: - On Mac, previously we checked whether the (2) directory had some particular subdirectories already when picking which one to use. This was removed; which directory is used is solely a question of whether the profile directory is in the standard location. I think the previous behavior was unpredictable. - On Linux, previously we only used behavior (2) if you hadn't changed your user-data-directory at all. Now, to match Mac, as long as your user-data-dir is in the standard place, you use the system cache dir. So e.g. using ~/.config/foobar puts your cache in ~/.cache/foobar. - On Linux, previously the default cache would end up as directories under ~/.cache/google-chrome/; now it ends up as directories under ~/.cache/google-chrome/Default/. (In all instances above, on Linux we continue to obey $XDG_CACHE_HOME.) BUG=59824 TEST=New test ChromePaths.UserCacheDir Review URL: http://codereview.chromium.org/5123004 TBR=evan@chromium.org Review URL: http://codereview.chromium.org/5344003 TBR=viettrungluu@chromium.org git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67202 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 67191 - chrome_paths: refactor and sanitize cache directory handlingviettrungluu@chromium.org2010-11-241-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Checking to see if this build failures on Windows.] Previously we had a bunch of logic in profile_impl.cc that computed where the cache directory lives. This change relocates it to chrome_paths.cc. Some background on cache directories. There are two possible places to store cache files: 1) in the user data directory 2) in an OS-specific user cache directory On Windows, we always pick (1). On Mac and Linux, we currently use (2) in some circumstances. This patch changes both Mac and Linux to have the same behavior with respect to (2). The Mac/Linux shared behavior is that if the profile directory is in the standard location for profiles, we put the cache files into a matching directory name in the standard system cache directory (e.g. on Linux if you're using ~/.config/google-chrome, your cache ends up in ~/.cache/google-chrome; on Mac, the directories are ~/Library/Application Support versus ~/Library/Caches). If your user data directory is not in the standard location, we use behavior (1). The semantic changes of this patch should be: - On Mac, previously we checked whether the (2) directory had some particular subdirectories already when picking which one to use. This was removed; which directory is used is solely a question of whether the profile directory is in the standard location. I think the previous behavior was unpredictable. - On Linux, previously we only used behavior (2) if you hadn't changed your user-data-directory at all. Now, to match Mac, as long as your user-data-dir is in the standard place, you use the system cache dir. So e.g. using ~/.config/foobar puts your cache in ~/.cache/foobar. - On Linux, previously the default cache would end up as directories under ~/.cache/google-chrome/; now it ends up as directories under ~/.cache/google-chrome/Default/. (In all instances above, on Linux we continue to obey $XDG_CACHE_HOME.) BUG=59824 TEST=New test ChromePaths.UserCacheDir Review URL: http://codereview.chromium.org/5123004 TBR=evan@chromium.org Review URL: http://codereview.chromium.org/5344003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67201 0039d316-1c4b-4281-b951-d872f2087c98
* chrome_paths: refactor and sanitize cache directory handlingevan@chromium.org2010-11-241-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we had a bunch of logic in profile_impl.cc that computed where the cache directory lives. This change relocates it to chrome_paths.cc. Some background on cache directories. There are two possible places to store cache files: 1) in the user data directory 2) in an OS-specific user cache directory On Windows, we always pick (1). On Mac and Linux, we currently use (2) in some circumstances. This patch changes both Mac and Linux to have the same behavior with respect to (2). The Mac/Linux shared behavior is that if the profile directory is in the standard location for profiles, we put the cache files into a matching directory name in the standard system cache directory (e.g. on Linux if you're using ~/.config/google-chrome, your cache ends up in ~/.cache/google-chrome; on Mac, the directories are ~/Library/Application Support versus ~/Library/Caches). If your user data directory is not in the standard location, we use behavior (1). The semantic changes of this patch should be: - On Mac, previously we checked whether the (2) directory had some particular subdirectories already when picking which one to use. This was removed; which directory is used is solely a question of whether the profile directory is in the standard location. I think the previous behavior was unpredictable. - On Linux, previously we only used behavior (2) if you hadn't changed your user-data-directory at all. Now, to match Mac, as long as your user-data-dir is in the standard place, you use the system cache dir. So e.g. using ~/.config/foobar puts your cache in ~/.cache/foobar. - On Linux, previously the default cache would end up as directories under ~/.cache/google-chrome/; now it ends up as directories under ~/.cache/google-chrome/Default/. (In all instances above, on Linux we continue to obey $XDG_CACHE_HOME.) BUG=59824 TEST=New test ChromePaths.UserCacheDir Review URL: http://codereview.chromium.org/5123004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67191 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "chrome_paths: refactor and sanitize cache directory handling"evan@chromium.org2010-11-231-9/+0
| | | | | | This reverts commit r67160, test failures. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67171 0039d316-1c4b-4281-b951-d872f2087c98
* chrome_paths: refactor and sanitize cache directory handlingevan@chromium.org2010-11-231-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we had a bunch of logic in profile_impl.cc that computed where the cache directory lives. This change relocates it to chrome_paths.cc. Some background on cache directories. There are two possible places to store cache files: 1) in the user data directory 2) in an OS-specific user cache directory On Windows, we always pick (1). On Mac and Linux, we currently use (2) in some circumstances. This patch changes both Mac and Linux to have the same behavior with respect to (2). The Mac/Linux shared behavior is that if the profile directory is in the standard location for profiles, we put the cache files into a matching directory name in the standard system cache directory (e.g. on Linux if you're using ~/.config/google-chrome, your cache ends up in ~/.cache/google-chrome; on Mac, the directories are ~/Library/Application Support versus ~/Library/Caches). If your user data directory is not in the standard location, we use behavior (1). The semantic changes of this patch should be: - On Mac, previously we checked whether the (2) directory had some particular subdirectories already when picking which one to use. This was removed; which directory is used is solely a question of whether the profile directory is in the standard location. I think the previous behavior was unpredictable. - On Linux, previously we only used behavior (2) if you hadn't changed your user-data-directory at all. Now, to match Mac, as long as your user-data-dir is in the standard place, you use the system cache dir. So e.g. using ~/.config/foobar puts your cache in ~/.cache/foobar. - On Linux, previously the default cache would end up as directories under ~/.cache/google-chrome/; now it ends up as directories under ~/.cache/google-chrome/Default/. (In all instances above, on Linux we continue to obey $XDG_CACHE_HOME.) BUG=59824 TEST=New test ChromePaths.UserCacheDir Review URL: http://codereview.chromium.org/5123004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67160 0039d316-1c4b-4281-b951-d872f2087c98
* Dynamic policy refresh support for the Mac.mnissler@chromium.org2010-10-291-0/+4
| | | | | | | | | | | Adapt the file watching code we already had for ConfigDirPolicyProvider to support a loader delegate, make the old code use it and change the Mac policy provider to watch for changes to the plist file in /Library/Managed Preferences/<username>. BUG=52040 TEST=unit tests Review URL: http://codereview.chromium.org/4062002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@64415 0039d316-1c4b-4281-b951-d872f2087c98
* FBTF: Remove unneeded headers from base/ (part 6)thestig@chromium.org2010-08-191-2/+3
| | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/3093013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56641 0039d316-1c4b-4281-b951-d872f2087c98
* `#pragma once` for app, base, chrome, gfx, ipc, net, skia, viewsthakis@chromium.org2010-07-261-0/+1
| | | | | | | | | BUG=50273 TEST=everything still builds, build is 10% faster on windows, same speed on mac/linux TBR: erg git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53716 0039d316-1c4b-4281-b951-d872f2087c98
* Mac: app mode loader (shim).viettrungluu@chromium.org2010-05-181-0/+7
| | | | | | | | | | | | Define an interface using which Chrome can be loaded from a minimal loader. Produce a binary for this loader (which can be put into a bundle). BUG=13148 TEST=not yet Review URL: http://codereview.chromium.org/2066004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47576 0039d316-1c4b-4281-b951-d872f2087c98
* Default to FOLDERID_Downloads on Windows Vista/7 when safe.dimich@google.com2010-01-251-0/+5
| | | | | | | | | Landing for DCheng@. Codereview: http://codereview.chromium.org/553040 TEST=none BUG=13610 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37023 0039d316-1c4b-4281-b951-d872f2087c98
* Move some XDG code from chrome to base, make DIR_USER_CACHE generic rather ↵thestig@chromium.org2009-12-021-5/+0
| | | | | | | | | | than Chromium specific, and clean up a few headers. BUG=none TEST=none Review URL: http://codereview.chromium.org/449048 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33565 0039d316-1c4b-4281-b951-d872f2087c98
* Remove the Chrome Frame preprocessor define in chrome_constants.cc and deal ↵robertshield@chromium.org2009-10-281-0/+5
| | | | | | | | | | | | with resulting fallout. Also, remove several instances of Chrome Frame using wstrings instead of FilePaths. The main goal of this patch is to move towards ensuring that Chrome Frame and Google Chrome share binary-identical exes and dlls except for setup.exe and mini_installer.exe. Review URL: http://codereview.chromium.org/338025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30290 0039d316-1c4b-4281-b951-d872f2087c98
* Don't use NSBundle when unsure of thread safety.mark@chromium.org2009-10-151-9/+0
| | | | | | | | BUG=24842 TEST=unit tests pass, app still works Review URL: http://codereview.chromium.org/271094 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29077 0039d316-1c4b-4281-b951-d872f2087c98
* Move the framework and helper application into a versioned directory in supportmark@chromium.org2009-10-141-0/+11
| | | | | | | | | | | | | | | | | | | | | | of unbreaking auto-update. BUG=14610 TEST= - The following bundles should be gone: - Chromium.app/Contents/Frameworks/Chromium Framework.framework - Chromium.app/Contents/Resources/Chromium Helper.app They should be replaced by: - Chromium.app/Contents/Versions/*/Chromium Framework.framework - Chromium.app/Contents/Versions/*/Chromium Helper.app - The application should continue to function properly and all tests should still pass. - The signed application should have the inner framework and helper application signed, and the outer application signed. The outer seal should permit unknown versions to be present in the Versions directory, but should protect the active versioned directory. - Auto-updating to an official build with this change should still work. Review URL: http://codereview.chromium.org/261031 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28963 0039d316-1c4b-4281-b951-d872f2087c98
* Fix 10% Mac startup time regression. Use +[NSBundle bundleWithPath:] insteadmark@chromium.org2009-10-071-1/+1
| | | | | | | | | | of +[NSBundle bundleWithIdentifier:] or +[NSBundle bundleForClass:]. BUG=24118 14610 TEST=Mac startup time should improve Review URL: http://codereview.chromium.org/268011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28339 0039d316-1c4b-4281-b951-d872f2087c98
* Move all resources into the framework.mark@chromium.org2009-10-071-6/+10
| | | | | | | | | | | | | | BUG=14610 (in support of unbreaking auto-update) TEST=The .app's Contents/Resources folder should not contain the resources that are moving to the .framework's Resources folder; The .app's Contents/Resources folder should still contain app.icns, document.icns, the helper .app, and a whole slew of .lprojs that only contain InfoPlist.strings; Make sure Breakpad still works in the browser, renderer, and other process types. Review URL: http://codereview.chromium.org/256062 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28262 0039d316-1c4b-4281-b951-d872f2087c98
* Tweak the comment in the lproj fixup script to explain why we need an "en" ↵thomasvl@chromium.org2009-08-241-1/+8
| | | | | | | | | | | | | | | | | | | | | | folder. Added a string for the products short name, this is current mac only, and is used for the application menu title via the infoplist.strings file. Added source for a tool to build InfoPlist.strings files based on the values within the GRD files. Run the InfoPlist.strings generation tool during the build. Added a script to take a string and list of locale and generate all the versions of the string. Wired up the string locale tool so GYP knows about all the inputs/outputs from the InfoPlist.strings generation tool. Stop setting some of the Info.plist keys that are now covered by the InfoPlist.strings files. Update the mac links script to stop creating a resources link. Add a shim to nuke the helper's resource link so it can get a real folder. Helper in in chrome_paths_mac to find the main app's bundle (that the helper lives in). At startup, if not the browser, set the main bundle to be the parent of this bundle. Fix up the breakpad init to use the mac_util helper for main bundle. TEST=when runnining in the supported languages, Finder Get Info should show a localized copyright. The process names in activity monitor should also be correct and show localized names once the TC work is done. BUG=19019 Review URL: http://codereview.chromium.org/171040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24104 0039d316-1c4b-4281-b951-d872f2087c98
* Use $XDG_CACHE_HOME for the cache on Linux. This only works for the default ↵thestig@chromium.org2009-08-111-0/+7
| | | | | | | | | | profile. BUG=16976 TEST=Run Chromium, visit some webpages, make sure it's using the cache under $XDG_CACHE_HOME (~/.cache by default) Review URL: http://codereview.chromium.org/159028 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23057 0039d316-1c4b-4281-b951-d872f2087c98
* Instead of appending "Downloads" to the user document directory, let each ↵estade@chromium.org2009-02-281-2/+4
| | | | | | | | | | platform specify its own downloads directory. On mac this is unimplemented. On windows it remains the user document directory + "\Downloads\", and on linux we attempt to follow their XDG setting, but fall back to ~/Downloads if they have an unsafe value in their XDG setting. Review URL: http://codereview.chromium.org/28167 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10669 0039d316-1c4b-4281-b951-d872f2087c98
* Factor out platform specific chrome_paths calls into platform specific files.tc@google.com2009-02-031-0/+26
Review URL: http://codereview.chromium.org/19760 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9088 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-06 19:18:21 +0000