| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
BUG=138542
TBR=mark@chromium.org
NOPRESUBMIT=true
Review URL: https://codereview.chromium.org/1538743002
Cr-Commit-Position: refs/heads/master@{#366910}
|
|
|
|
|
|
|
|
| |
This leaves a "using" statement in to allow landing without updating all callers atomically.
Review URL: https://codereview.chromium.org/1371463003
Cr-Commit-Position: refs/heads/master@{#350896}
|
|
|
|
|
|
|
|
|
|
| |
64-bit and 32-bit platforms.
BUG=
Review URL: https://codereview.chromium.org/986373006
Cr-Commit-Position: refs/heads/master@{#320498}
|
|
|
|
|
|
|
|
|
|
|
| |
Not used except for cloud print.
BUG=426573
TBR=rvargas
Review URL: https://codereview.chromium.org/681533002
Cr-Commit-Position: refs/heads/master@{#301473}
|
|
|
|
|
|
|
|
|
|
|
| |
This updates the includes in base but leaves a forwarding header for the rest of the project for now.
R=yzshen@chromium.org
Review URL: https://codereview.chromium.org/468253002
Cr-Commit-Position: refs/heads/master@{#289360}
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@289360 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Quick Launch shortcut.
InstallShortcutTest.CreateAllShortcutsSystemLevel has been broken since http://crrev.com/164849 ...
The test expectations had not been adjusted in this CL as setup_unittests.exe
doesn't run on the waterfall yet (issue #153829) and the breakage had gone
unnoticed.
Expectations have now been adjusted such that we no longer expect a system-level
(Default-user) Quick Launch shortcut, but a per-user Quick Launch shortcut for
the admin running the install as the product code's logic has been doing for over
a year...
Also remove the code cleaning up the legacy Default-user Quick Launch shortcut as
this cleanup code has been running for 21 months now and leaving this shortcut
behind for a few users is a no-op (i.e. the Default-user shortcut will get copied
to new Windows profiles and Active Setup will kick in a few seconds later to try
to install the same shortcut which will already exist... the UX result will be
the same: a single Chrome Quick Launch shortcut will be installed).
BUG=329239, 153829
Review URL: https://codereview.chromium.org/432273005
Cr-Commit-Position: refs/heads/master@{#288393}
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@288393 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note: this is a reland of https://codereview.chromium.org/258743005
This change implements some of the DBus stub methods so that enterprise enrollment works on desktop builds. That will make development of features that depend on enrollment faster for developers that use this workflow (e.g. for kiosk enterprise apps, public accounts, testing some device policies, etc).
- Override some of the directories and files involved with the enrollment state
- Simple stub implementation of the DBus calls involved
- Write a persistent cache of the install attributes
- Cleaned up the stub for user cloud policy and made them persistent too
- Updated some tests
This change doesn't affect production code.
TBR=jochen@chromium.org
BUG=240269, 367674
Review URL: https://codereview.chromium.org/264943011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@267861 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(https://codereview.chromium.org/258743005/)
Reason for revert:
It seems to have broken the following test from
base_unittests and unit_tests on chromium.webkit Android Tests (dbg) builder:
PathServiceTest.Override
Log: http://build.chromium.org/p/chromium.webkit/builders/Android%20Tests%20%28dbg%29/builds/18922
Snippet from log:
C 237s Main [FAIL] PathServiceTest.Override:
C 237s Main ../../base/path_service_unittest.cc:184: Failure
C 237s Main Value of: PathService::OverrideAndCreateIfNeeded(my_special_key,
non_existent, false, false)
C 237s Main Actual: true
C 237s Main Expected: false
Original issue's description:
> Enable Enterprise enrollment on desktop builds.
>
> This change implements some of the DBus stub methods so that enterprise enrollment works on desktop builds. That will make development of features that depend on enrollment faster for developers that use this workflow (e.g. for kiosk enterprise apps, public accounts, testing some device policies, etc).
>
> - Override some of the directories and files involved with the enrollment state
> - Simple stub implementation of the DBus calls involved
> - Write a persistent cache of the install attributes
> - Cleaned up the stub for user cloud policy and made them persistent too
> - Updated some tests
>
> This change doesn't affect production code.
>
> TBR=jochen@chromium.org
> BUG=240269, 367674
>
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=267640
TBR=brettw@chromium.org,nkostylev@chromium.org,pastarmovj@chromium.org,satorux@chromium.org,jochen@chromium.org,joaodasilva@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=240269, 367674
Review URL: https://codereview.chromium.org/265013002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@267761 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change implements some of the DBus stub methods so that enterprise enrollment works on desktop builds. That will make development of features that depend on enrollment faster for developers that use this workflow (e.g. for kiosk enterprise apps, public accounts, testing some device policies, etc).
- Override some of the directories and files involved with the enrollment state
- Simple stub implementation of the DBus calls involved
- Write a persistent cache of the install attributes
- Cleaned up the stub for user cloud policy and made them persistent too
- Updated some tests
This change doesn't affect production code.
TBR=jochen@chromium.org
BUG=240269, 367674
Review URL: https://codereview.chromium.org/258743005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@267640 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
R=viettrungluu@chromium.org
TBR=viettrungluu
Review URL: https://codereview.chromium.org/184563006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@255418 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unifies the Path Service's base::DIR_HOME on Posix and base::DIR_PROFILE on Windows to just be base::DIR_HOME everywhere, and DIR_HOME will now work on Mac.
This removes the AssertIOAllowed check in the Posix implementation because that was only executed in a fallback case that no developer is likely to ever hit. In addition, the we do call this type of function on the UI thread, so either we need to promote the assertion to be at the top of the function or delete it. It seemed unreasonable to disallow using this one key of the path service on the UI thread (the other ones are OK) so I just went for deleting the assertion.
R=benwells@chromium.org
Review URL: https://codereview.chromium.org/159833003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@252066 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=
TBR=jam@chromium.org
Review URL: https://codereview.chromium.org/18286004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@211147 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
BUG=247723
TEST=none
TBR=ben@chromium.org
Review URL: https://chromiumcodereview.appspot.com/16667013
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@205261 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=163208
TEST=none
Review URL: https://codereview.chromium.org/12829005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@189130 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
TBR=sky
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@184344 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
This is im preparation for removing the 'using" in file_path.h
Review URL: https://codereview.chromium.org/12286020
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@183021 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
R=cpu@chromium.org,mark@chromium.org
BUG=168890
Review URL: https://chromiumcodereview.appspot.com/12035095
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@178932 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
Also add to base namespace.
BUG=
Review URL: https://codereview.chromium.org/11359217
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@168281 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
NOTRY=True
BUG=None
TBR=willchan
Review URL: https://chromiumcodereview.appspot.com/11359220
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@167801 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pinned-to-taskbar shortcuts owned by the uninstalled Chrome.
Original commit http://crrev.com/165505
Reverted in http://crrev.com/165524
BUG=158632
TEST=No user-level shortcut Chrome left behind in taskbar post user-level self-destruct.
Review URL: https://chromiumcodereview.appspot.com/11368040
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166285 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is especially useful for unit tests because they live in the same process
and share all the singletons including PathService. One can of course override
the overrides but it is much cleaner and sometimes the only good solution to
return to the original PathProvider instead.
BUG=149161
TEST=base_unittests:PathServiceTest.*
Review URL: https://chromiumcodereview.appspot.com/10909228
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@158842 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
DIR_USER_DESKTOP does not apply on iOS, so exclude it from the set of paths that
are tested.
BUG=b/151050
Review URL: https://chromiumcodereview.appspot.com/10970019
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@158607 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
folders.
Re-commit, reverted in http://crrev.com/157680 (original commit in http://crrev.com/157667).
This allows usage of PathService to cache the shortcut install paths and more importantly to mock them in shortcut tests!
Also move chrome::DIR_USER_DESKTOP to base::DIR_USER_DESKTOP; this is really where it belongs. In fact it is only in chrome_paths.h because it used to be called DIR_DEFAULT_DOWNLOAD and cpu@ renamed it to DIR_USER_DESKTOP in http://crrev.com/1753 (early days!) after that it started to be used all over the place as the Desktop path. Finally bringing it to base_paths.h, beside DIR_START_MENU and friends, is the right thing to do imo.
TBR=brettw@chromium.org
BUG=148539
TEST=Quick Launch shortcut installed in the right place on XP (both Default and current user)
Desktop shortcuts installed in the right place (both All Users and per-user installs).
installer_util_unittests.exe --gtest_filter=ShellUtilShortcutTest*
unit_tests.exe --gtest_filter=ProfileShortcutManagerTest*
base_unittests --gtest_filter=PathServiceTest*
Review URL: https://chromiumcodereview.appspot.com/10964007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157779 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Quick Launch folders.
The previous patch failed PathServiceTest.Get.
This allows usage of PathService to cache the paths and more importantly to mock them in shortcut tests!
Also move chrome::DIR_USER_DESKTOP to base::DIR_USER_DESKTOP; this is really where it belongs. In fact it is only in chrome_paths.h because it used to be called DIR_DEFAULT_DOWNLOAD and cpu@ renamed it to DIR_USER_DESKTOP in http://crrev.com/1753 (early days!) after that it started to be used all over the place as the Desktop path. Finally bringing it to base_paths.h, beside DIR_START_MENU and friends, is the right thing to do imo.
BUG=148539
TEST=Quick Launch shortcut installed in the right place on XP (both Default and current user)
Desktop shortcuts installed in the right place (both All Users and per-user installs).
installer_util_unittests.exe --gtest_filter=ShellUtilShortcutTest*
unit_tests.exe --gtest_filter=ProfileShortcutManagerTest*
base_unittests --gtest_filter=PathServiceTest*
Review URL: https://chromiumcodereview.appspot.com/10910209
TBR=gab@chromium.org
Review URL: https://codereview.chromium.org/10958009
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157680 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
folders.
This allows usage of PathService to cache the paths and more importantly to mock them in shortcut tests!
Also move chrome::DIR_USER_DESKTOP to base::DIR_USER_DESKTOP; this is really where it belongs. In fact it is only in chrome_paths.h because it used to be called DIR_DEFAULT_DOWNLOAD and cpu@ renamed it to DIR_USER_DESKTOP in http://crrev.com/1753 (early days!) after that it started to be used all over the place as the Desktop path. Finally bringing it to base_paths.h, beside DIR_START_MENU and friends, is the right thing to do imo.
BUG=148539
TEST=Quick Launch shortcut installed in the right place on XP (both Default and current user)
Desktop shortcuts installed in the right place (both All Users and per-user installs).
installer_util_unittests.exe --gtest_filter=ShellUtilShortcutTest*
unit_tests.exe --gtest_filter=ProfileShortcutManagerTest*
base_unittests --gtest_filter=PathServiceTest*
Review URL: https://chromiumcodereview.appspot.com/10910209
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157667 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
The Windows secondary tiles deletion functions are only available to Chrome itself when running in metro mode. To get around this, the folder containing the installation's secondarty tiles is removed entirely.
BUG=140559
Review URL: https://chromiumcodereview.appspot.com/10876057
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@154103 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is prerequisite for adding support for running chrome on network
shared location
BUG=120388
TEST=base_unittests:PathServiceTest.Override
Review URL: https://chromiumcodereview.appspot.com/10388027
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@136017 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=
TEST=
Review URL: http://codereview.chromium.org/7701014
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@98432 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This reverts commit r67160, test failures.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67171 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
TEST=Fix PathServiceTest.Get on POSIX on new slaves
BUG=none
Review URL: http://codereview.chromium.org/4023006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63649 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
base/win/windows_version. Many files now only need to include this instead of all of win_util.
Remove a bunch of unused code from base/win_util. There was a surprising amount.
Replace the AppUserModel property key with the one from the SDK now that we use the Win7 SDK. Move GetLogonSessionOnlyDACL from win_util to ipc since it's only used in that one place.
TEST=it compiles
BUG=none
Review URL: http://codereview.chromium.org/3823002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@62694 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Added implementation of GetUserCacheDirectory() for OS X.
- Added FilePath::GetRelativePath().
- Implemented per-profile cache directories for OS X.
Patch by Fred Akalin <akalin@gmail.com>
Code review URL: http://codereview.chromium.org/174053
Review URL: http://codereview.chromium.org/204043
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26387 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
Landing patch for Thiago Farina, original review: http://codereview.chromium.org/187005
BUG=None
TEST=run unit_tests.exe, base_unittests.exe.
Review URL: http://codereview.chromium.org/193101
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26142 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/42155
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11593 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
Normalize end of file newlines in base/. All files end in a single newline.
Review URL: http://codereview.chromium.org/42011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11329 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
* Add support for "Debug On Start" switch to MultiprocessTest::SpawnChild
Review URL: http://codereview.chromium.org/13052
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6227 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
- Add some transition APIs.
- Start migrating some code to transition APIs.
Review URL: http://codereview.chromium.org/8825
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4254 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
and teardown hooks. On the Mac use this to create an outer Autorelease pool.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1089 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@650 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
making it timeout on the test bot. Also simplify the test code.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@546 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@533 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
dependencies in path_service.cc.
One questionable decision here was to put GetCurrentDirectory and SetCurrentDirectory into file_util_win.cc. I could have kept the logic in path_service.cc with #ifdefs or I could have split up path_service.cc into path_service_win.cc, etc.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@436 0039d316-1c4b-4281-b951-d872f2087c98
|
|
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8 0039d316-1c4b-4281-b951-d872f2087c98
|