summaryrefslogtreecommitdiffstats
path: root/base
Commit message (Collapse)AuthorAgeFilesLines
* Turn off field trials and reporting of metrics when running benchmarking.mbelshe@google.com2010-12-072-2/+32
| | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/5628005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68532 0039d316-1c4b-4281-b951-d872f2087c98
* Wrap GlobalDescriptors singleton in accessor method.evan@chromium.org2010-12-072-0/+11
| | | | | | | | | | | When I switched GlobalDescriptors to using LeakySingletonTraits in r67627, it didn't occur to me I had to fix all users of it. TEST=compiles Review URL: http://codereview.chromium.org/5517006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68518 0039d316-1c4b-4281-b951-d872f2087c98
* Making a few RegKey methods that only read data, const.tommi@chromium.org2010-12-072-11/+12
| | | | | | | | | | | This is so that we can make methods that don't alter the contained HKEY or the data it represents accept const references of RegKey. TEST=none BUG=none Review URL: http://codereview.chromium.org/5623004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68489 0039d316-1c4b-4281-b951-d872f2087c98
* Avoid recursive DisplayDebugMessageInDialog call when an assert is hit on ↵joth@chromium.org2010-12-071-0/+4
| | | | | | | | | | | the IO thread BUG=None TEST=Hacked code to call NOTREACHED() from IO thread. Review URL: http://codereview.chromium.org/5614003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68468 0039d316-1c4b-4281-b951-d872f2087c98
* JavaScript to Value bridge.scottbyer@google.com2010-12-072-0/+12
| | | | | | | | | | | | Add more values that we can get back from JavaScript. Very useful for writing additional DOMUI browser test, and maybe in other cases as well. BUG=none TEST=RenderViewHostTest.ExecuteJavascriptInWebFrameNotifyResult Review URL: http://codereview.chromium.org/4924001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68416 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for Bug 50726 "Save extension list and "winning" prefs from extensions"bauerb@chromium.org2010-12-063-0/+34
| | | | | | | | | | | | | | | | | | | This is a redesign for http://codereview.chromium.org/4852002/ following discussions. The goal of this patch is to ensure that Chrome maintains the order in which extensions apply their preferences between restarts. This may be an issue if two extensions overwrite each others preferences. Furthermore, it ensures that preferences are persisted to disk between browser restarts. Therefore, previous settings are immediately available when the browser is restarted. A description of the design has been published https://docs.google.com/a/google.com/document/d/1E_HX_cUpET1gH2gDunGIU1EOywMM6FEOuVU6TlpnSwo/edit?hl=en for review and comments. - Sorry, accessible Google internally only. This CL requires http://codereview.chromium.org/5204006/ Contributed by battre@google.com BUG=50726 TEST=none Review URL: http://codereview.chromium.org/5213002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68355 0039d316-1c4b-4281-b951-d872f2087c98
* A non-GTK version of menus for touchui.sadrul@chromium.org2010-12-053-5/+49
| | | | | | | | | | | | For the menus to work correctly, the X messge pump also needs updating to allow nested event dispatching. BUG=None TEST=On a touchui build, non-GTK context menus in web-pages should work correctly. Review URL: http://codereview.chromium.org/5110011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68309 0039d316-1c4b-4281-b951-d872f2087c98
* This CL add a GetInstance() method to singleton classes instead of relying ↵satish@chromium.org2010-12-0412-81/+117
| | | | | | | | | | | | | | | | | on the callers to use Singleton<T>. In some cases I have used the LazyInstance<T> pattern as that was simpler. This is a small step towards making all singleton classes use the Singleton<T> pattern within their code and not expect the callers to know about it. I have selected all files under src/app and src/base which use Singleton<T> in this CL. Once this CL goes in I'll work on the rest of the files. BUG=65298 TEST=all existing tests should continue to pass. Review URL: http://codereview.chromium.org/5527004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68300 0039d316-1c4b-4281-b951-d872f2087c98
* Recommit 68258 - Mark some functions that wait on other processes as unsafe ↵victorw@chromium.org2010-12-041-0/+7
| | | | | | | | | | | | | | | | | | | for IO/UI. This might have helped catch an earlier bug, where we were shelling out to lsb_release on Linux. BUG=21782 Review URL: http://codereview.chromium.org/4149006 TBR=evan@chromium.org Review URL: http://codereview.chromium.org/5625005 TBR=victorw@chromium.org Review URL: http://codereview.chromium.org/5588005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68277 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 68258 - Mark some functions that wait on other processes as unsafe ↵victorw@chromium.org2010-12-041-7/+0
| | | | | | | | | | | | | | | | for IO/UI. This might have helped catch an earlier bug, where we were shelling out to lsb_release on Linux. BUG=21782 Review URL: http://codereview.chromium.org/4149006 TBR=evan@chromium.org Review URL: http://codereview.chromium.org/5625005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68270 0039d316-1c4b-4281-b951-d872f2087c98
* Mark some functions that wait on other processes as unsafe for IO/UI.evan@chromium.org2010-12-041-0/+7
| | | | | | | | | | | This might have helped catch an earlier bug, where we were shelling out to lsb_release on Linux. BUG=21782 Review URL: http://codereview.chromium.org/4149006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68258 0039d316-1c4b-4281-b951-d872f2087c98
* base: Remove stub scoped_variant_win.h file.tfarina@chromium.org2010-12-042-10/+1
| | | | | | | | | | | Fix the callers and add base::win in the call sites. BUG=None TEST=trybots Review URL: http://codereview.chromium.org/5507001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68251 0039d316-1c4b-4281-b951-d872f2087c98
* Start using file_util symlink code, now that it's available.gspencer@chromium.org2010-12-034-17/+14
| | | | | | | | | | | | In CL http://codereview.chromium.org/5349007 I added some base API for manipulating symlinks (since I needed it for some ChromeOS code and noticed that other places could use it too), and this just starts using that API. BUG=none TEST=Ran ui_tests, passed trybots. Review URL: http://codereview.chromium.org/5286010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68181 0039d316-1c4b-4281-b951-d872f2087c98
* scons: excise more scons references from the code baseevan@chromium.org2010-12-032-3/+3
| | | | | | | | | | I got to undo some hacks, too! TEST=compiles Review URL: http://codereview.chromium.org/5535003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68119 0039d316-1c4b-4281-b951-d872f2087c98
* Fix crash when the silent extension install policy is set to an empty listgfeher@chromium.org2010-12-021-1/+2
| | | | | | | | | | | Empty lists were not properly handled when the policy was refreshed. BUG=64871 TEST=ExtensionManagementTest.ExternalPolicyRefresh Review URL: http://codereview.chromium.org/5472002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67988 0039d316-1c4b-4281-b951-d872f2087c98
* Update prcpucfg.h to build in Native Client.abarth@chromium.org2010-12-021-1/+1
| | | | | | | | | | Native Client is similar to Linux, but it does not define __linux__. http://codereview.chromium.org/5479001/ git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67985 0039d316-1c4b-4281-b951-d872f2087c98
* A quick fix for Bug 64463.hbono@chromium.org2010-12-021-1/+1
| | | | | | | | | | It seems scoped_refptr<MessageLoopProxy>::~scoped_refptr() cannot call MessageLoopProxyImpl::~MessageLoopProxyImpl() because it is not a virtual destructor. This change just changes it to a virtual one. BUG=64463 TEST=make the valgrind bots green. Review URL: http://codereview.chromium.org/5321012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67976 0039d316-1c4b-4281-b951-d872f2087c98
* Eliminate 'if defiend(CHECK) to avoid having to different binaries for the ↵oshima@chromium.org2010-12-021-1/+5
| | | | | | | | | | | | | | | same template function. There is a new crash report but not caught by the CHECKS. (http://crash/reportdetail?reportid=accf4c24431527ce#crashing_thread) This could be because this ifdef generates two different objects of this template function and linker may be picking bad one. BUG=chromium-os:7327 TEST=none Review URL: http://codereview.chromium.org/5405003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67913 0039d316-1c4b-4281-b951-d872f2087c98
* linux: remove split base_extra_target from base.gypjam@chromium.org2010-12-011-232/+166
| | | | | | | Previously we built part of base twice under different configurations. This reverts r49502 (http://codereview.chromium.org/2796002), since we don't need a separate fpic base target now that all of Linux is built with fpic. Review URL: http://codereview.chromium.org/5361011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67893 0039d316-1c4b-4281-b951-d872f2087c98
* Make sure that cached values of signed settings are trusted.dilmah@chromium.org2010-12-011-1/+1
| | | | | | | | | | | Verify them at least once since startup. BUG=chromium-os:8645 TEST=Manual Review URL: http://codereview.chromium.org/5185001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67846 0039d316-1c4b-4281-b951-d872f2087c98
* Help make Base compile under NaClabarth@chromium.org2010-12-012-5/+10
| | | | | | | | | | This patch is a first attempt to get MessageLoop working inside NaCl. I suspect we'll need to do something more complicated at some point, but this version passes at least a few of the unit tests. Review URL: http://codereview.chromium.org/5435001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67832 0039d316-1c4b-4281-b951-d872f2087c98
* Help make base compile under NaClabarth@chromium.org2010-12-011-0/+15
| | | | | | | | | | | | This file requires a few tweaks to run under Native Client. For example, there isn't a NaCl API to determine whether the process is being debugged and int3 isn't a valid NaCl instruction. Original patch by Eric Seidel. Review URL: http://codereview.chromium.org/5423002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67827 0039d316-1c4b-4281-b951-d872f2087c98
* Help make base compile in NaCl.abarth@chromium.org2010-12-011-0/+6
| | | | | | | | | | Turns out intptr_t isn't 64 bits wide in 64-bit NaCl. This class assumes that Atomic64 is actually 64 bits wide, so we need to use the int64_t type instead. Original patch by Eric Seidel. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67826 0039d316-1c4b-4281-b951-d872f2087c98
* windows: remove PathService::Get() that uses wstringsevan@chromium.org2010-11-302-17/+0
| | | | | | | | | | This just required fixing the remaining callers. BUG=24672 Review URL: http://codereview.chromium.org/5356008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67783 0039d316-1c4b-4281-b951-d872f2087c98
* net: Remove typedef net::URLRequest URLRequest;tfarina@chromium.org2010-11-301-5/+5
| | | | | | | | | BUG=64263 TEST=compiled locally, trybots Review URL: http://codereview.chromium.org/5384002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67762 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 67662 - FBTF: Remove unneeded headers from base/ (part 10)thestig@chromium.org2010-11-301-0/+1
| | | | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/5139006 TBR=thestig@chromium.org Review URL: http://codereview.chromium.org/5270010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67674 0039d316-1c4b-4281-b951-d872f2087c98
* FBTF: Remove unneeded headers from base/ (part 10)thestig@chromium.org2010-11-301-1/+0
| | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/5139006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67662 0039d316-1c4b-4281-b951-d872f2087c98
* Some additions to support symlinks better on platforms that support them.gspencer@chromium.org2010-11-307-11/+78
| | | | | | | | | BUG=none TEST=Ran new unit test, passed trybots. Review URL: http://codereview.chromium.org/5349007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67631 0039d316-1c4b-4281-b951-d872f2087c98
* Moved the calls to the MessageLoop destruction observers to after the ↵sanjeevr@chromium.org2010-11-302-4/+68
| | | | | | | | | | | | pending tasks are deleted. BUG=None TEST=Unit-test provided, tests should pass and all hell should not break loose. Review URL: http://codereview.chromium.org/5318003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67623 0039d316-1c4b-4281-b951-d872f2087c98
* Remove a pair of overly aggressive DCHECKsjar@chromium.org2010-11-291-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consistency checks (to detect memory corruption) were disabled for non-standard derived forms of histograms (some cache stats were using histograms a bit differently). When I added a virtual function to allow such derived classes to override the checking code, I forgot I had some inline DCHECKs as well. The method for getting the total_count was still DCHECKing the consistency, and there was another consistency assertion made when gathering data for upload to UMA. Both of these DCHECKs, which were not overridden, were removed. They were there to assure my code was working, and to detect memory smashers (or broken DRAM) more quickly... but are too hard to cleanly override (for the one histogram that does not support this facility). BUG=61281 BUG=64268 r=jam Review URL: http://codereview.chromium.org/5365004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67608 0039d316-1c4b-4281-b951-d872f2087c98
* Make base's fork of ICU macros use its internal version for one case that wasbrettw@chromium.org2010-11-291-1/+1
| | | | | | | | | | forgotten before. TEST=it compiles BUG=none Review URL: http://codereview.chromium.org/5270009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67601 0039d316-1c4b-4281-b951-d872f2087c98
* Add a unit test for CommandLine that makes sure that GetProgram will not ↵tommi@chromium.org2010-11-291-0/+19
| | | | | | | | | | | return a quoted string and that (on Windows) the program part of a command line string will always be quoted. BUG=none TEST=Run the ProgramQuotes test. Should be no visible changes. Review URL: http://codereview.chromium.org/4949004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67583 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "base: wait for children to terminate."agl@chromium.org2010-11-291-55/+43
| | | | | | | This reverts commit r67562, it caused some test failures which I need to look at. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67573 0039d316-1c4b-4281-b951-d872f2087c98
* base: wait for children to terminate.agl@chromium.org2010-11-291-43/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | I screwed up and assumed that you can't race the kernel. But it turns out that it's possible to obverse a child in the process of dying. The kernel will close the child's file descriptors before waitpid knows that the child is dead. Rather than rewrite everything (in an area of the code which has had lots of issues in the past), I'm opting to do a blocking wait for the child to die. The code higher up already copes with waitpid() failing, but we'll miss some crashes if it does. With this patch, we'll wait up to 250ms for the termination information on a child. We are, no doubt, blocking a latency sensitive thread with this. However, the race window in the kernel is small, so doesn't really block for > a millisecond or so. We do have to consider the case where a buggy child closes its file descriptor without dying. In that case, we'll block for the full 250ms but that indicates a serious bug in the child. BUG=63531 TEST=nagivating to about:gpucrash on linux and checking the we know that the child crashed. http://codereview.chromium.org/5377001/ git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67572 0039d316-1c4b-4281-b951-d872f2087c98
* Make ScopedTempDir::Delete return a bool so that its functionality can be ↵tommi@chromium.org2010-11-293-6/+37
| | | | | | | | | | | tested. TEST=Run the new unit test: ScopedTempDir.LockedTempDir BUG=none Review URL: http://codereview.chromium.org/5340004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67551 0039d316-1c4b-4281-b951-d872f2087c98
* Check if the frame belongs to the browser tree associated with the BHO ↵siggi@chromium.org2010-11-251-0/+5
| | | | | | | | | | | | | | | | | before commiting to creating and binding handlers. Also, replace CComPtr with ScopedPtrHandler. Committing for motek@google.com, original review at http://codereview.chromium.org/5311003/. TEST=unittests in change. BUG=3205224 BUG=3166440 Review URL: http://codereview.chromium.org/5360003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67415 0039d316-1c4b-4281-b951-d872f2087c98
* Make sure third_party/dmg_fp/dtoa.cc is compiled threadsafe.siggi@chromium.org2010-11-252-1/+41
| | | | | | | | | BUG=64353 TEST=none Review URL: http://codereview.chromium.org/5321008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67414 0039d316-1c4b-4281-b951-d872f2087c98
* Fixed warning on empty --v switch (this time for reals)akalin@chromium.org2010-11-251-5/+6
| | | | | | | | | BUG=None TEST=Manual Review URL: http://codereview.chromium.org/5364001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67360 0039d316-1c4b-4281-b951-d872f2087c98
* This is another try to commit OOM priority management.gspencer@chromium.org2010-11-241-1/+1
| | | | | | | | | | | | | This changes nothing, except that I now initialize memory_used in oom_priority_manager.cc to placate the incorrect gcc warning about it being used when uninitialized. The original review is here: http://codereview.chromium.org/4498001/ BUG=none TEST=Passed chromeos try-bot, built both debug and release locally. Review URL: http://codereview.chromium.org/5328003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67342 0039d316-1c4b-4281-b951-d872f2087c98
* Initial conversion of download unit test to browser test with enhancedrdsmith@google.com2010-11-242-0/+66
| | | | | | | | | | | download completion detection (DownloadsObserver). BUG=None TEST=browser_tests --gtest_filter=DownloadTest.DownloadMimeType Review URL: http://codereview.chromium.org/4658001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67279 0039d316-1c4b-4281-b951-d872f2087c98
* Cleanup AdjustStringForLocaleDirection() to modify input parameter in place.jeremy@chromium.org2010-11-242-32/+17
| | | | | | | | | | | As described in the bug, the current behavior is confusing and bug-prone. BUG=47194 TEST=Check that there are no visible regressions in RTL and LTR language UIs on Linux & Windows. Review URL: http://codereview.chromium.org/5154009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67237 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 67201 - Revert 67191 - chrome_paths: refactor and sanitize cache ↵viettrungluu@chromium.org2010-11-246-21/+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-246-9/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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-246-21/+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 67175 - This change implements OOM priority management for ChromeOSviettrungluu@chromium.org2010-11-231-1/+1
| | | | | | | | | | | | | | | | (Build failure, probably debug/release warning difference.) This adds periodic OOM score adjustment, based on the last access time of the tab, whether or not it is pinned, and (of course) how much memory it is using. BUG=http://crosbug.com/8990 TEST=Ran some ui_tests, ran on device. Review URL: http://codereview.chromium.org/4498001 TBR=gspencer@chromium.org Review URL: http://codereview.chromium.org/5284003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67183 0039d316-1c4b-4281-b951-d872f2087c98
* Stop using Hard Coded copies of GUID strings in RGS files.mad@google.com2010-11-232-0/+90
| | | | | | | | | BUG=0 TEST=Make sure everything works after unregistration and re-registration. Review URL: http://codereview.chromium.org/5113005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67180 0039d316-1c4b-4281-b951-d872f2087c98
* This change implements OOM priority management for ChromeOSgspencer@chromium.org2010-11-231-1/+1
| | | | | | | | | | | This adds periodic OOM score adjustment, based on the last access time of the tab, whether or not it is pinned, and (of course) how much memory it is using. BUG=http://crosbug.com/8990 TEST=Ran some ui_tests, ran on device. Review URL: http://codereview.chromium.org/4498001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67175 0039d316-1c4b-4281-b951-d872f2087c98
* Fix shutdown crash in CertVerifier by using a MessageLoopProxy.willchan@chromium.org2010-11-232-1/+7
| | | | | | | | | | | The CertVerifier is not getting Cancel()'d because something which owns it is getting leaked, most likely a URLRequestJob. Therefore, we can end up accessing a deleted MessageLoop on shutdown. MessageLoopProxy prevents accessing a deleted MessageLoop on shutdown, instead it just deletes the task, which isn't great, but it's better than crashing. We should fix the root cause eventually, which is a leak of the URLRequestJob. BUG=42275,chromium-os:8179 TEST=none Review URL: http://codereview.chromium.org/5347001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67172 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "chrome_paths: refactor and sanitize cache directory handling"evan@chromium.org2010-11-236-7/+25
| | | | | | 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-236-25/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
generated by cgit v1.1 at 2025-02-01 01:00:05 +0000