summaryrefslogtreecommitdiffstats
path: root/base
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Fixed logging so that vmodule works correctly againakalin@chromium.org2010-11-233-9/+5
| | | | | | | | | | | | | | Removed extraneous check in LogMessage destructor; all the checks are now done before LogMessage is created. Removed useless warning if --vmodule is used but --v is not. BUG=None TEST=Manual Review URL: http://codereview.chromium.org/5329001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67131 0039d316-1c4b-4281-b951-d872f2087c98
* Add infrastructure enabling tests of installer upgrade scenarios.grt@chromium.org2010-11-231-3/+3
| | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/5236002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67099 0039d316-1c4b-4281-b951-d872f2087c98
* Implements openssl session cachingjoth@chromium.org2010-11-231-0/+2
| | | | | | | | | | | Also fixes up the ssl socket handling of the OpenSSL error stack, and resolves a few TODOs. BUG=None TEST=opening https: pages with vlog=3 enabled and expected the log Review URL: http://codereview.chromium.org/5100010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67087 0039d316-1c4b-4281-b951-d872f2087c98
* Dynamic refresh for the silent extension install policygfeher@chromium.org2010-11-233-0/+43
| | | | | | | | | | | Re-run ExternalPolicyExtensionProvider::VisitRegisteredExtension each time the policy-controlled preference prefs::kExtensionInstallForceList is changed. This will install new policy-controlled extensions. Those that are removed from the policy will only be uninstalled at next startup. BUG=63179 TEST=ExtensionManagementTest.ExternalPolicyRefresh Review URL: http://codereview.chromium.org/5120003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67078 0039d316-1c4b-4281-b951-d872f2087c98
* Reconstructing 67000.bradnelson@google.com2010-11-231-1/+1
| | | | | | | | | | | | | | (python24 -> python26). Regression in nacl fixed, new DEPS change. BUG=None TEST=NOne Review URL: http://codereview.chromium.org/5310001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67057 0039d316-1c4b-4281-b951-d872f2087c98
* Revert previous commit which was by accidentjabdelmalek@google.com2010-11-231-0/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67052 0039d316-1c4b-4281-b951-d872f2087c98
* Fix compile error on Linuxjabdelmalek@google.com2010-11-231-1/+0
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67051 0039d316-1c4b-4281-b951-d872f2087c98
* Make DeleteKey support GetLastError.tommi@chromium.org2010-11-231-1/+6
| | | | | | | | | | | | | | | | | | | | | | | When SHDeleteKey returns, the last error value hasn't been set. With this change, it's possible to have checks like: if (!key.DeleteKey(...) && GetLastError() != ERROR_NOT_FOUND) { HandleErrorCase(); return false; } return true; As it stands, the last error value will always be ERROR_SUCCESS, which is not all that useful. In fact there is code in the installer that attempts to do this, but doesn't currently work correctly (also because it's checking for the wrong GLE value, but I'm fixing that in a separate change). BUG=none TEST=Should have no side effects. Review URL: http://codereview.chromium.org/5182009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67049 0039d316-1c4b-4281-b951-d872f2087c98
* [Mac] Log registers with stackdump in debug crashes.shess@chromium.org2010-11-221-7/+51
| | | | | | | | | | | Expand |StackDumpSignalHandler()| to log register contents and part of the stack. BUG=60426 TEST=Bug's crashes get registers logged. Review URL: http://codereview.chromium.org/5243002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67012 0039d316-1c4b-4281-b951-d872f2087c98
* Switch to using kInvalidThreadId instead of 0.willchan@chromium.org2010-11-221-2/+2
| | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/5266001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67011 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 67000.bradnelson@google.com2010-11-221-1/+1
| | | | | | | | | | BUG=None TEST=None TBR=nsylvain Review URL: http://codereview.chromium.org/5272001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67004 0039d316-1c4b-4281-b951-d872f2087c98
* Switching chrome to use python26 in place of python24.bradnelson@google.com2010-11-221-1/+1
| | | | | | | | | BUG=None TEST=None Review URL: http://codereview.chromium.org/5121009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67000 0039d316-1c4b-4281-b951-d872f2087c98
* Fix ThreadChecker to use Locks and not use scoped_ptr.willchan@chromium.org2010-11-214-17/+26
| | | | | | | | | | | | | | | It needs to synchronize its checks, since in order to assert correctly, it needs to make sure the thread id is synchronized on all threads. It doesn't need scoped_ptr. It was trying to use NULL to catch invalid thread ids. 0 is already assumed to be invalid (see base::Thread's use). Eliminating scoped_ptr fixes a valgrind/heapcheck issue where they don't follow LazyInstance objects' member pointers. So they think the ThreadChecker's member variable is leaked, even though the global object still has a pointer to it. Removing the scoped_ptr.h caused a bunch of other lame files to fail to compile. I had to fix those places. #include what you use please :( TBR=levin (I want to green the memory bots) BUG=none TEST=none Review URL: http://codereview.chromium.org/5180006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66915 0039d316-1c4b-4281-b951-d872f2087c98
* Leak NSS to prevent shutdown crashes.willchan@chromium.org2010-11-211-59/+74
| | | | | | | | | | | NSS can be used by non-joinable threads (worker threads). These can access it after ~AtExitManager has already triggered the NSS shutdown code, so we can crash on shutdown. Therefore we leak NSS. BUG=61585 TEST=existing Review URL: http://codereview.chromium.org/5240001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66904 0039d316-1c4b-4281-b951-d872f2087c98
* FBTF: Remove unneeded headers from base/ (part 9)thestig@chromium.org2010-11-209-10/+5
| | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/5091005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66873 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes a crash in the Windows media player plugin caused when the Real player ↵ananta@chromium.org2010-11-192-3/+29
| | | | | | | | | | | | | | | | | | | | | | | recorder plugin is installed on the machine. This plugin intercepts LoadLibrary calls issued by chrome.dll and wraps NPAPI calls provided the actual plugin dll, in this case media player. This is to provide the Download this video functionality. Crash occurs probably due to an interacton with Real player and media player. Fix is to load the plugin dynamically via the exported kernel32 function LoadLibrary instead of invoking it via the LoadLibrary import from chrome.dll. This would bypass the recorder plugin. Fixes bug http://code.google.com/p/chromium/issues/detail?id=63552 Bug=63552 Test=Install real player and media player on the machine and navigate to the url mentioned in the bug. It should not crash Review URL: http://codereview.chromium.org/5190005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66839 0039d316-1c4b-4281-b951-d872f2087c98
* Reland 66791 (change was innocent)willchan@chromium.org2010-11-198-41/+180
| | | | | | | | | | | | | | | | | | | Revert 66719 - Reland r65996. Disallows Singletons on non-joinable thread. Test breakages caused by this change have been fixed here or in other changelists. BUG=61753 TEST=none Review URL: http://codereview.chromium.org/5024003 TBR=willchan@chromium.org Review URL: http://codereview.chromium.org/5206005 TBR=willchan@chromium.org Review URL: http://codereview.chromium.org/5242002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66808 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 66719 - Reland r65996. Disallows Singletons on non-joinable thread.willchan@chromium.org2010-11-198-180/+41
| | | | | | | | | | | | | | Test breakages caused by this change have been fixed here or in other changelists. BUG=61753 TEST=none Review URL: http://codereview.chromium.org/5024003 TBR=willchan@chromium.org Review URL: http://codereview.chromium.org/5206005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66791 0039d316-1c4b-4281-b951-d872f2087c98
* Fix openssl build to work with AllowSingleton changesjoth@chromium.org2010-11-191-3/+16
| | | | | | | | | BUG=61585 TEST=net & base unit tests; start & quit browser Review URL: http://codereview.chromium.org/5102006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66772 0039d316-1c4b-4281-b951-d872f2087c98
* Follow up comments on SymmetricKey::Import docsjoth@chromium.org2010-11-191-4/+4
| | | | | | | | | BUG=None TEST=None Review URL: http://codereview.chromium.org/5223001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66765 0039d316-1c4b-4281-b951-d872f2087c98
* Reland r65996. Disallows Singletons on non-joinable thread.willchan@chromium.org2010-11-198-41/+180
| | | | | | | | | | | Test breakages caused by this change have been fixed here or in other changelists. BUG=61753 TEST=none Review URL: http://codereview.chromium.org/5024003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66719 0039d316-1c4b-4281-b951-d872f2087c98
* FTP: improve character encoding detection in cases where ICU's first guess ↵phajdan.jr@chromium.org2010-11-182-5/+37
| | | | | | | | | | | | | | | | | | | is wrong. Instead of using ICU's first guessed encoding immediately, we ask it for all possible encodings, try them in order, and use the first one that works. For some sites this still results in a gibberish being displayed, but at least the links are clickable so the site navigation is possible. BUG=61073 TEST=see bug Review URL: http://codereview.chromium.org/4967001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66664 0039d316-1c4b-4281-b951-d872f2087c98
* Implements Signature Creator & Verifier for openssljoth@chromium.org2010-11-1810-49/+149
| | | | | | | | | | | Also adds a little more infrastructure to assist in openssl error handling. BUG=None TEST=base_unittests RSA* and Sign* Review URL: http://codereview.chromium.org/5105003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66622 0039d316-1c4b-4281-b951-d872f2087c98
* Reland http://codereview.chromium.org/4139008, with a differentaa@chromium.org2010-11-181-0/+13
| | | | | | | | | | | | approach to creating version numbers. The old one had troubles with timezones. This one is simpler and better. BUG=49233 TEST=Covered by unit tests Review URL: http://codereview.chromium.org/4471001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66582 0039d316-1c4b-4281-b951-d872f2087c98
* Add shared macros for stringizing and converting ANSI string constantsjoi@chromium.org2010-11-184-1/+119
| | | | | | | | | | | | | | | | | | | | | (in particular defined by macros) to wide string constants. Convert existing locally-defined stringizing to use the shared macros. Unit tests for the shared macros. This also fixes a minor bug in ceee_module_util.cc where I accidentally quoted a string constant I only meant to convert to wide (this caused no bug, but was unintended, so the change in semantics in that file in the current change is intentional). BUG=none TEST=automated tests Review URL: http://codereview.chromium.org/5103001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66579 0039d316-1c4b-4281-b951-d872f2087c98
* Remove a definition in a weird spot since it's only used on Solaris, which ↵thestig@chromium.org2010-11-181-8/+0
| | | | | | | | | | nobody is actively porting to right now. BUG=none TEST=none Review URL: http://codereview.chromium.org/5202001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66578 0039d316-1c4b-4281-b951-d872f2087c98
* Implements RSAPrivateKey for openssl.joth@chromium.org2010-11-172-31/+91
| | | | | | | | | | | Leaves the declared NSS-only methods (CreateSensitive.. & FindFromPublicKeyInfo) as UNIMPLEMENTED. BUG=None TEST=base_unittests --gtest_filter=RSA* Review URL: http://codereview.chromium.org/5047003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66438 0039d316-1c4b-4281-b951-d872f2087c98
* Original change: http://codereview.chromium.org/4856003/bulach@chromium.org2010-11-171-2/+2
| | | | | | | | | | | | | | | | (landing on behalf of kristianm) Suppress Android warnings Android generates warnings for comparing signed and unsigned numbers. The ones in this CL should be safe. BUG=62949 TEST=None Review URL: http://codereview.chromium.org/5035002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66420 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor EnsureOpenSSLInit and openssl_util into basejoth@chromium.org2010-11-175-1/+84
| | | | | | | | | | | | This allows the base/crypto methods to call EnsureOpenSSLInit. Also factors out the SSL_CTX and X509_STORE to be more closely associated with their consumers (ssl socket and X509Certificate resp.) rather than process wide globals. BUG=None TEST=None Review URL: http://codereview.chromium.org/4963002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66413 0039d316-1c4b-4281-b951-d872f2087c98
* Only need to depend on Foundation here, not Cocoa.thomasvl@chromium.org2010-11-161-1/+1
| | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/5095001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66331 0039d316-1c4b-4281-b951-d872f2087c98
* Switch to ptrdiff_t instead of std::ptrdiff_t since we seem to use raw ↵thomasvl@chromium.org2010-11-161-2/+2
| | | | | | | | | | ptrdiff_t in other places. BUG=none TEST=none Review URL: http://codereview.chromium.org/5085001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66293 0039d316-1c4b-4281-b951-d872f2087c98
* The UI language rather than the locale is now used to pick Chrome's language ↵grt@chromium.org2010-11-167-21/+248
| | | | | | | | | | | | | | | on Windows. (Also fixed some unrelated lint errors.) With this change, l10n_util::GetApplicationLocale first checks for an override of the "configured locale" (in base::i18n) containing the list of preferred Windows UI languages. The browser triggers an override early in startup before the ApplicationLocale is determined. In effect, the browser no longer uses ICU on Windows for language detection. (This locale override mechanism is borrowed from the OS X port.) Changes in Chrome Frame are largely a refactor, as some Win32 code in there has been moved into base/win. Also cleaned up language selection in installer_util so that the proper language is chosen for the EULA, installer messages, and shortcuts. In so doing, replaced hand-crafted lists of supported languages with either auto-generated lists (static consts) or logic so that the addition of translations in the future doesn't require code motion (that being said, there may be reason to update the alias and/or wildcard tables in language_selector.cc). In so doing, this change unlocks Amharic, Farsi, and Swahili translations for installer messages and shortcuts. BUG=39986,40496,26470 TEST=New MUI/Win32 calls are tested in base/win/i18n_unittest.cc. To test the overall functionality, uninstall Chrome, remove intl.app_locale user pref, switch to a supported display language (via the "Keyboards and Languages" tab of Win7's "Regional and Language" control panel, and install with { "distribution": { "require_eula": true } } in master_preferences (via -installerdata arg to setup.exe). If all goes well, both EULA and outer frame are in the same language as Windows. Also, from gwilson: "Install system-level Chrome in audit mode on a new machine, then go through the out-of-box-experience, select a language, and the in -product EULA (triggered by "require_eula" : true) and Chrome's UI should be in the language that the user selected." Review URL: http://codereview.chromium.org/4139010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66275 0039d316-1c4b-4281-b951-d872f2087c98
* Chrome Frame: Add explicit object security attributes to the Chrome Frame ↵robertshield@chromium.org2010-11-162-8/+9
| | | | | | | | | | | | | version beacon. This will allow low integrity processes to access shared memory segment and lock and make shared memory segment read only after creation. Also use lock names that include the hosting process. BUG=61609 TEST=Start medium integrity Chrome Frame host running CF version X. Update CF to version Y > X. Start low integrity Chrome Frame host, observe that version X is loaded. Review URL: http://codereview.chromium.org/5012001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66270 0039d316-1c4b-4281-b951-d872f2087c98
* Move ToUpperASCII into base namespace, to make it consistent with ToLowerASCIIjoth@chromium.org2010-11-161-7/+7
| | | | | | | | | | | This mirrors the change made in http://src.chromium.org/viewvc/chrome?view=rev&revision=64879 BUG=None TEST=everything builds; base unit tests pass Review URL: http://codereview.chromium.org/5007001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66261 0039d316-1c4b-4281-b951-d872f2087c98
* Clarify some documentation on SymmetricKeyjoth@chromium.org2010-11-161-3/+7
| | | | | | | | | BUG=None TEST=None Review URL: http://codereview.chromium.org/5013001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66259 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-01 00:37:46 +0000