summaryrefslogtreecommitdiffstats
path: root/base/prefs/json_pref_store_unittest.cc
Commit message (Collapse)AuthorAgeFilesLines
* Expand the JsonPrefStore's interface to allow for an alternate filename to ↵gab@chromium.org2014-06-201-1/+203
| | | | | | | | | | | | be specified. The alternate filename is intended to be the old name of the pref file being read, JsonPrefStore handles the migration if required. JsonPrefStore's FileThreadDeserializer is the best place to do this as it's the only code in the prefs stack running on a thread allowed to do IO (another solution would be to let JsonPrefStore take a PreReadOnFileThreadCallback to abstract the required work away, but the direct approach seemed easier here without breaking encapsulation). BUG=372547 Review URL: https://codereview.chromium.org/347793002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@278776 0039d316-1c4b-4281-b951-d872f2087c98
* Move preference MACs to the protected preference stores.erikwright@chromium.org2014-06-181-1/+1
| | | | | | | | | | | | | | | | | | | (1) 1-time migration of MACs from local state to Preferences/Protected Preferences. (2) Migrate MACs between Preferences/Protected Preferences according to configuration changes. Proposed follow-up tasks are: (1) Introduce TrackedPreferencesMigrationDelegate (2) Introduce protections to prevent unintended stamping of the super MAC. (3) Expanded test coverage of PrefHashFilter (4) Expanded test coverage for legacy migration in TrackedPreferencesMigrationTest BUG=372547, 368480 R=asvitkine@chromium.org, gab@chromium.org Review URL: https://codereview.chromium.org/324493002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@278164 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce a new framework for back-and-forth tracked preference migrationgab@chromium.org2014-05-121-4/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | between Protected Preferences and unprotected Preferences. Migration from unprotected Preferences to Protected Preferences was previously done after both stores had been initialized. This was inherently incorrect as some operations (PrefHashFilter::FilterOnLoad) would occur before the values had been moved to the proper store. It also introduced a weird method in PrefHashFilter::MigrateValues which required an independent PrefHashFilter (backed by a copy of the real PrefHashStore). This after-the-fact migration caused Settings.TrackedPreferenceCleared spikes when changing a value from being enforced to not being enforced (as we'd have a MAC, but no value yet in this store when running FilterOnLoad()) and more importantly it also caused issue 365769 -- both of these issues highlight the incorrectness of the current approach. The migration back from Protected Preferences to unprotected Preferences when enforcement was disabled was using yet another mechanism which would only kick in when a given pref was written to (ref. old non-const SegregatedPrefStore::StoreForKey()). The new framework intercepts PrefFilter::FilterOnLoad() events for both stores and does the back-and-forth migration in place before it even hands them back to the PrefFilter::FinalizeFilterOnLoad() which then hands it back to the JsonPrefStores (so that they are agnostic to the migration; from their point of view their values were always in their store as they received it). Furthermore, this new framework will easily allow us to later move MACs out of Local State into their respective stores (which is a task on our radar which we currently have no easy way to accomplish). The new framework also handles read errors better. For example, it was previously possible for the unprotected->protected migration to result in data loss if the protected store was somehow read-only from a read error while the unprotected store wasn't -- resulting in an in-memory migration only flushed to disk in the store from which the value was deleted... The new framework handles those cases, preferring temporary data duplication over potential data loss (duplicated data is cleaned up once confirmation is obtained that the new authority for this data has been successfully written to disk -- it will even try again in following Chrome runs if it doesn't succeed in this one). Note: This CL helped LSAN discover an existing leak in post_task_and_reply_impl.cc, see issue 371974 for details. BUG=365769, 371974 TEST= A) Make sure all kTrackedPrefs consistently report Settings.TrackedPreferenceUnchanged across changes from various enforcement levels (using --force-fieldtrials). B) Make sure the prefs are properly migrated to their new store (and subsequently cleaned up from their old store) when changing the enforcement_level across multiple runs. C) Make sure prefs are properly migrated in a quick startup/shutdown with a new enforcement_level and that their old value is properly cleaned up in a subsequent startup at the same enforcement_level (or re-migrated at another enforcement_level). R=bauerb@chromium.org, robertshield@chromium.org, stuartmorgan@chromium.org, thakis@chromium.org Initially Committed in: https://src.chromium.org/viewvc/chrome?view=rev&revision=269346 Reverted in: https://src.chromium.org/viewvc/chrome?view=rev&revision=269367 Committed again: https://src.chromium.org/viewvc/chrome?view=rev&revision=269415 Reverted again: https://src.chromium.org/viewvc/chrome?view=rev&revision=269438 Review URL: https://codereview.chromium.org/257003007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269735 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 269415 "Introduce a new framework for back-and-forth trac..."ananta@chromium.org2014-05-091-172/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reverting because this appears to have caused Linux TSAN redness. > Introduce a new framework for back-and-forth tracked preference migration > between Protected Preferences and unprotected Preferences. > > Migration from unprotected Preferences to Protected Preferences was previously > done after both stores had been initialized. This was inherently incorrect as > some operations (PrefHashFilter::FilterOnLoad) would occur before the values > had been moved to the proper store. It also introduced a weird method in > PrefHashFilter::MigrateValues which required an independent PrefHashFilter > (backed by a copy of the real PrefHashStore). This after-the-fact migration > caused Settings.TrackedPreferenceCleared spikes when changing a value from > being enforced to not being enforced (as we'd have a MAC, but no value yet in > this store when running FilterOnLoad()) and more importantly it also caused > issue 365769 -- both of these issues highlight the incorrectness of the > current approach. > > The migration back from Protected Preferences to unprotected Preferences when > enforcement was disabled was using yet another mechanism which would only kick > in when a given pref was written to (ref. old non-const > SegregatedPrefStore::StoreForKey()). > > The new framework intercepts PrefFilter::FilterOnLoad() events for both stores > and does the back-and-forth migration in place before it even hands them back > to the PrefFilter::FinalizeFilterOnLoad() which then hands it back to the > JsonPrefStores (so that they are agnostic to the migration; from their point > of view their values were always in their store as they received it). > Furthermore, this new framework will easily allow us to later move MACs out of > Local State into their respective stores (which is a task on our radar which > we currently have no easy way to accomplish). > > The new framework also handles read errors better. For example, it was > previously possible for the unprotected->protected migration to result in data > loss if the protected store was somehow read-only from a read error while the > unprotected store wasn't -- resulting in an in-memory migration only flushed > to disk in the store from which the value was deleted... The new framework > handles those cases, preferring temporary data duplication over potential data > loss (duplicated data is cleaned up once confirmation is obtained that the new > authority for this data has been successfully written to disk -- it will even > try again in following Chrome runs if it doesn't succeed in this one). > > Note: This CL helped LSAN discover an existing leak in post_task_and_reply_impl.cc, see issue 371974 for details. > > BUG=365769, 371974 > TEST= > A) Make sure all kTrackedPrefs consistently report > Settings.TrackedPreferenceUnchanged across changes from various enforcement > levels (using --force-fieldtrials). > B) Make sure the prefs are properly migrated to their new store (and > subsequently cleaned up from their old store) when changing the > enforcement_level across multiple runs. > C) Make sure prefs are properly migrated in a quick startup/shutdown with a > new enforcement_level and that their old value is properly cleaned up in a > subsequent startup at the same enforcement_level (or re-migrated at another > enforcement_level). > > R=bauerb@chromium.org, robertshield@chromium.org, stuartmorgan@chromium.org, thakis@chromium.org > > Initially Committed in: https://src.chromium.org/viewvc/chrome?view=rev&revision=269346 > Reverted in: https://src.chromium.org/viewvc/chrome?view=rev&revision=269367 > > Review URL: https://codereview.chromium.org/257003007 TBR=gab@chromium.org Review URL: https://codereview.chromium.org/273243002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269438 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce a new framework for back-and-forth tracked preference migrationgab@chromium.org2014-05-091-4/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | between Protected Preferences and unprotected Preferences. Migration from unprotected Preferences to Protected Preferences was previously done after both stores had been initialized. This was inherently incorrect as some operations (PrefHashFilter::FilterOnLoad) would occur before the values had been moved to the proper store. It also introduced a weird method in PrefHashFilter::MigrateValues which required an independent PrefHashFilter (backed by a copy of the real PrefHashStore). This after-the-fact migration caused Settings.TrackedPreferenceCleared spikes when changing a value from being enforced to not being enforced (as we'd have a MAC, but no value yet in this store when running FilterOnLoad()) and more importantly it also caused issue 365769 -- both of these issues highlight the incorrectness of the current approach. The migration back from Protected Preferences to unprotected Preferences when enforcement was disabled was using yet another mechanism which would only kick in when a given pref was written to (ref. old non-const SegregatedPrefStore::StoreForKey()). The new framework intercepts PrefFilter::FilterOnLoad() events for both stores and does the back-and-forth migration in place before it even hands them back to the PrefFilter::FinalizeFilterOnLoad() which then hands it back to the JsonPrefStores (so that they are agnostic to the migration; from their point of view their values were always in their store as they received it). Furthermore, this new framework will easily allow us to later move MACs out of Local State into their respective stores (which is a task on our radar which we currently have no easy way to accomplish). The new framework also handles read errors better. For example, it was previously possible for the unprotected->protected migration to result in data loss if the protected store was somehow read-only from a read error while the unprotected store wasn't -- resulting in an in-memory migration only flushed to disk in the store from which the value was deleted... The new framework handles those cases, preferring temporary data duplication over potential data loss (duplicated data is cleaned up once confirmation is obtained that the new authority for this data has been successfully written to disk -- it will even try again in following Chrome runs if it doesn't succeed in this one). Note: This CL helped LSAN discover an existing leak in post_task_and_reply_impl.cc, see issue 371974 for details. BUG=365769, 371974 TEST= A) Make sure all kTrackedPrefs consistently report Settings.TrackedPreferenceUnchanged across changes from various enforcement levels (using --force-fieldtrials). B) Make sure the prefs are properly migrated to their new store (and subsequently cleaned up from their old store) when changing the enforcement_level across multiple runs. C) Make sure prefs are properly migrated in a quick startup/shutdown with a new enforcement_level and that their old value is properly cleaned up in a subsequent startup at the same enforcement_level (or re-migrated at another enforcement_level). R=bauerb@chromium.org, robertshield@chromium.org, stuartmorgan@chromium.org, thakis@chromium.org Initially Committed in: https://src.chromium.org/viewvc/chrome?view=rev&revision=269346 Reverted in: https://src.chromium.org/viewvc/chrome?view=rev&revision=269367 Review URL: https://codereview.chromium.org/257003007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269415 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 269346 "Introduce a new framework for back-and-forth trac..."rlp@chromium.org2014-05-091-164/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fails JsonPrefStoreTest.RemoveClearsEmptyParent on Linux ASan. http://build.chromium.org/p/chromium.memory/builders/Linux%20ASan%20LSan%20Tests%20%281%29/builds/2074/steps/base_unittests/logs/RemoveClearsEmptyParent > Introduce a new framework for back-and-forth tracked preference migration > between Protected Preferences and unprotected Preferences. > > Migration from unprotected Preferences to Protected Preferences was previously > done after both stores had been initialized. This was inherently incorrect as > some operations (PrefHashFilter::FilterOnLoad) would occur before the values > had been moved to the proper store. It also introduced a weird method in > PrefHashFilter::MigrateValues which required an independent PrefHashFilter > (backed by a copy of the real PrefHashStore). This after-the-fact migration > caused Settings.TrackedPreferenceCleared spikes when changing a value from > being enforced to not being enforced (as we'd have a MAC, but no value yet in > this store when running FilterOnLoad()) and more importantly it also caused > issue 365769 -- both of these issues highlight the incorrectness of the > current approach. > > The migration back from Protected Preferences to unprotected Preferences when > enforcement was disabled was using yet another mechanism which would only kick > in when a given pref was written to (ref. old non-const > SegregatedPrefStore::StoreForKey()). > > The new framework intercepts PrefFilter::FilterOnLoad() events for both stores > and does the back-and-forth migration in place before it even hands them back > to the PrefFilter::FinalizeFilterOnLoad() which then hands it back to the > JsonPrefStores (so that they are agnostic to the migration; from their point > of view their values were always in their store as they received it). > Furthermore, this new framework will easily allow us to later move MACs out of > Local State into their respective stores (which is a task on our radar which > we currently have no easy way to accomplish). > > The new framework also handles read errors better. For example, it was > previously possible for the unprotected->protected migration to result in data > loss if the protected store was somehow read-only from a read error while the > unprotected store wasn't -- resulting in an in-memory migration only flushed > to disk in the store from which the value was deleted... The new framework > handles those cases, preferring temporary data duplication over potential data > loss (duplicated data is cleaned up once confirmation is obtained that the new > authority for this data has been successfully written to disk -- it will even > try again in following Chrome runs if it doesn't succeed in this one). > > BUG=365769 > TEST= > A) Make sure all kTrackedPrefs consistently report > Settings.TrackedPreferenceUnchanged across changes from various enforcement > levels (using --force-fieldtrials). > B) Make sure the prefs are properly migrated to their new store (and > subsequently cleaned up from their old store) when changing the > enforcement_level across multiple runs. > C) Make sure prefs are properly migrated in a quick startup/shutdown with a > new enforcement_level and that their old value is properly cleaned up in a > subsequent startup at the same enforcement_level (or re-migrated at another > enforcement_level). > > R=bauerb@chromium.org, stuartmorgan@chromium.org, thakis@chromium.org > > Review URL: https://codereview.chromium.org/257003007 TBR=gab@chromium.org Review URL: https://codereview.chromium.org/279943002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269367 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce a new framework for back-and-forth tracked preference migrationgab@chromium.org2014-05-091-4/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | between Protected Preferences and unprotected Preferences. Migration from unprotected Preferences to Protected Preferences was previously done after both stores had been initialized. This was inherently incorrect as some operations (PrefHashFilter::FilterOnLoad) would occur before the values had been moved to the proper store. It also introduced a weird method in PrefHashFilter::MigrateValues which required an independent PrefHashFilter (backed by a copy of the real PrefHashStore). This after-the-fact migration caused Settings.TrackedPreferenceCleared spikes when changing a value from being enforced to not being enforced (as we'd have a MAC, but no value yet in this store when running FilterOnLoad()) and more importantly it also caused issue 365769 -- both of these issues highlight the incorrectness of the current approach. The migration back from Protected Preferences to unprotected Preferences when enforcement was disabled was using yet another mechanism which would only kick in when a given pref was written to (ref. old non-const SegregatedPrefStore::StoreForKey()). The new framework intercepts PrefFilter::FilterOnLoad() events for both stores and does the back-and-forth migration in place before it even hands them back to the PrefFilter::FinalizeFilterOnLoad() which then hands it back to the JsonPrefStores (so that they are agnostic to the migration; from their point of view their values were always in their store as they received it). Furthermore, this new framework will easily allow us to later move MACs out of Local State into their respective stores (which is a task on our radar which we currently have no easy way to accomplish). The new framework also handles read errors better. For example, it was previously possible for the unprotected->protected migration to result in data loss if the protected store was somehow read-only from a read error while the unprotected store wasn't -- resulting in an in-memory migration only flushed to disk in the store from which the value was deleted... The new framework handles those cases, preferring temporary data duplication over potential data loss (duplicated data is cleaned up once confirmation is obtained that the new authority for this data has been successfully written to disk -- it will even try again in following Chrome runs if it doesn't succeed in this one). BUG=365769 TEST= A) Make sure all kTrackedPrefs consistently report Settings.TrackedPreferenceUnchanged across changes from various enforcement levels (using --force-fieldtrials). B) Make sure the prefs are properly migrated to their new store (and subsequently cleaned up from their old store) when changing the enforcement_level across multiple runs. C) Make sure prefs are properly migrated in a quick startup/shutdown with a new enforcement_level and that their old value is properly cleaned up in a subsequent startup at the same enforcement_level (or re-migrated at another enforcement_level). R=bauerb@chromium.org, stuartmorgan@chromium.org, thakis@chromium.org Review URL: https://codereview.chromium.org/257003007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269346 0039d316-1c4b-4281-b951-d872f2087c98
* Add a unit test for JsonPrefStore::Remove.dgrogan@chromium.org2014-01-301-0/+21
| | | | | | Review URL: https://codereview.chromium.org/144633002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@247915 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a race condition in preference metric reporting.erikwright@chromium.org2013-12-231-10/+26
| | | | | | | | | | | | | | | | | | Introduces: - PrefFilter: An interface to intercept preference values as they are loaded from disk, before any changes are possible. - PrefHashFilter: An implementation that verifies preference values against hashes in a PrefHashStore. - PrefHashStore(Impl): An interface and implementation for storing and verifying hashes of preferences. - PrefHashCalculator: A utility for calculating preference value hashes. TBR=brettw (base/base.gyp), scottbyer (chrome/service/service_process_prefs.cc) BUG=321680 NOTRY=True Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=242382 Review URL: https://codereview.chromium.org/90563003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@242407 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 242382 "Fix a race condition in preference metric reporting."danakj@chromium.org2013-12-231-26/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | This broke android causing test crashes: http://build.chromium.org/p/chromium.linux/builders/Android%20Tests%20%28dbg%29/builds/17336/steps/chromiumtestshell_instrumentation_tests/logs/stdio http://chromegw.corp.google.com/i/clank.tot/builders/instrumentation-yakju-clankium-tot/builds/21056/steps/Run%20stack%20tool%20with%20logcat%20dump/logs/stdio > Fix a race condition in preference metric reporting. > > Introduces: > - PrefFilter: An interface to intercept preference values as they are loaded from disk, before any changes are possible. > - PrefHashFilter: An implementation that verifies preference values against hashes in a PrefHashStore. > - PrefHashStore(Impl): An interface and implementation for storing and verifying hashes of preferences. > - PrefHashCalculator: A utility for calculating preference value hashes. > > TBR=brettw (base/base.gyp), scottbyer (chrome/service/service_process_prefs.cc) > BUG=321680 > NOTRY=True > > Review URL: https://codereview.chromium.org/90563003 TBR=erikwright@chromium.org Review URL: https://codereview.chromium.org/120803002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@242388 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a race condition in preference metric reporting.erikwright@chromium.org2013-12-231-10/+26
| | | | | | | | | | | | | | | | Introduces: - PrefFilter: An interface to intercept preference values as they are loaded from disk, before any changes are possible. - PrefHashFilter: An implementation that verifies preference values against hashes in a PrefHashStore. - PrefHashStore(Impl): An interface and implementation for storing and verifying hashes of preferences. - PrefHashCalculator: A utility for calculating preference value hashes. TBR=brettw (base/base.gyp), scottbyer (chrome/service/service_process_prefs.cc) BUG=321680 NOTRY=True Review URL: https://codereview.chromium.org/90563003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@242382 0039d316-1c4b-4281-b951-d872f2087c98
* Remove JsonPrefStore pruning of empty values on write.gab@chromium.org2013-11-271-47/+27
| | | | | | | | | | | | | Written from https://codereview.chromium.org/12092021 The entire source code was surveyed for existing list/dict prefs for which this change could be problematic, it doesn't look like anything is relying on this internal detail of the API, see this for details: https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AtwXJ4IPPZBAdG9rX3RTc3k5Z1pyN3U4b3d4Tkota3c#gid=0 TBR=joth (for minor android_webview side-effects) BUG=323346 Review URL: https://codereview.chromium.org/81183005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@237473 0039d316-1c4b-4281-b951-d872f2087c98
* Rename base::Delete to base::DeleteFilebrettw@chromium.org2013-07-161-1/+1
| | | | | | | | | | | Also renames DeleteAfterReboot to DeleteFileAfterReboot, and removes FileUtilProxy::RecursiveDelete which was never called. BUG= R=shess@chromium.org Review URL: https://codereview.chromium.org/18584011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@211822 0039d316-1c4b-4281-b951-d872f2087c98
* Move PathIsWritable, DirectoryExists, ContentsEqual, and TextContentsEqual ↵brettw@chromium.org2013-07-151-4/+3
| | | | | | | | | | to the base namespace. TBR=sky Review URL: https://codereview.chromium.org/19052005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@211675 0039d316-1c4b-4281-b951-d872f2087c98
* Move PathExists to base namespace.brettw@chromium.org2013-07-111-10/+10
| | | | | | | | | 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
* Move Copy* into the base namespace.brettw@chromium.org2013-07-091-4/+4
| | | | | | | | | | | This also creates a new base::internal namespace in file_util and I moved some of the internal functions in file_util to there. BUG= TBR=jam Review URL: https://codereview.chromium.org/18332014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@210600 0039d316-1c4b-4281-b951-d872f2087c98
* Move file_util::Delete to the base namespacebrettw@chromium.org2013-07-011-1/+1
| | | | | | | | BUG= Review URL: https://codereview.chromium.org/16950028 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@209475 0039d316-1c4b-4281-b951-d872f2087c98
* Call scoped_refptr<T>::get() rather than relying on implicit "operator T*"rsleevi@chromium.org2013-06-111-14/+8
| | | | | | | | | | | | | | | | | | | This upates calls to bound temporary objects to also use get(). While it has the same semantic equivalence to the existing code, this generally represents a dangerous pattern - indeed, part of the whole motivation for this change is to make this anti-pattern very visible to authors. This change simply updates all of the call sites, to allow the "operator T*" to be removed and preventing new instances. The existing instances will then be reviewed for "suspicious" changes and updated to use/pass scoped_refptr<T> rather than T*, as appropriate. BUG=110610 TBR=darin Review URL: https://codereview.chromium.org/15984016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@205560 0039d316-1c4b-4281-b951-d872f2087c98
* Use a direct include of strings headers in base/.avi@chromium.org2013-06-101-1/+1
| | | | | | | | | | 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
* Use a direct include of utf_string_conversions.h in android_webview/, apps/, ↵avi@chromium.org2013-06-071-1/+1
| | | | | | | | | | | ash/, base/. BUG=none TEST=none Review URL: https://chromiumcodereview.appspot.com/15735027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@204874 0039d316-1c4b-4281-b951-d872f2087c98
* Update base/ to use scoped_refptr<T>::get() rather than implicit "operator T*"rsleevi@chromium.org2013-05-311-6/+4
| | | | | | | | | | | Linux fixes BUG=110610 TBR=darin Review URL: https://chromiumcodereview.appspot.com/16160015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@203483 0039d316-1c4b-4281-b951-d872f2087c98
* base: Consolidate all test data directories under base/test/data.tfarina@chromium.org2013-04-071-6/+1
| | | | | | | | | | | | This is the follow up patch I promised in r191077 - https://chromiumcodereview.appspot.com/12481028 TEST=base_unittests R=darin@chromium.org,bulach@chromium.org Review URL: https://codereview.chromium.org/13376002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@192780 0039d316-1c4b-4281-b951-d872f2087c98
* Replace FilePath with base::FilePath.brettw@chromium.org2013-02-171-15/+15
| | | | | | | | 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
* Move string_number_conversions to base/strings.brettw@chromium.org2013-02-071-1/+1
| | | | | | | | | | This only updates includes in base and keeps a forwarding header for now to keep the change under control. BUG= Review URL: https://codereview.chromium.org/12092078 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@181161 0039d316-1c4b-4281-b951-d872f2087c98
* base: Convert the remaining uses of MessageLoop::RunUntilIdle to RunLoop ↵tfarina@chromium.org2013-02-061-2/+2
| | | | | | | | | | | | | | | | variant. The former method is deprecated and actually it is just using RunLoop internally. The later is the cannonical method and should be used instead. BUG=131220 TEST=base_unittests R=darin@chromium.org Review URL: https://chromiumcodereview.appspot.com/12226007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@180991 0039d316-1c4b-4281-b951-d872f2087c98
* base: Convert MessageLoop::RunUntilIdle() cases to base::RunLoop variant.tfarina@chromium.org2013-02-051-2/+3
| | | | | | | | | | | | | | The former method is deprecated and actually it is just using RunLoop internally. The later is the cannonical method and should be used instead. BUG=131220 TEST=base_unittests R=darin@chromium.org Review URL: https://chromiumcodereview.appspot.com/12184007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@180641 0039d316-1c4b-4281-b951-d872f2087c98
* base: Do not use Value::Create* functions.tfarina@chromium.org2012-12-161-8/+8
| | | | | | | | | | BUG=160586 R=willchan@chromium.org,estade@chromium.org Review URL: https://chromiumcodereview.appspot.com/11519026 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@173368 0039d316-1c4b-4281-b951-d872f2087c98
* base/prefs: Break the dependency in chrome_paths.htfarina@chromium.org2012-11-271-3/+8
| | | | | | | | | | | BUG=155525 TEST=unit_tests --gtest_filter=JsonPrefStoreTest* R=joi@chromium.org Review URL: https://chromiumcodereview.appspot.com/11411159 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@169701 0039d316-1c4b-4281-b951-d872f2087c98
* base/prefs: Break the dependency on chrome/common/pref_names.htfarina@chromium.org2012-11-221-2/+3
| | | | | | | | | | BUG=155525 TEST=unit_tests R=joi@chromium.org Review URL: https://codereview.chromium.org/11414133 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@169310 0039d316-1c4b-4281-b951-d872f2087c98
* Move scoped_temp_dir from base to base/filesbrettw@chromium.org2012-11-161-2/+2
| | | | | | | | | | 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
* Change PrefStore::ReadResult to a boolean.bauerb@chromium.org2012-11-081-11/+8
| | | | | | | | | | | The third value in the enum (READ_USE_DEFAULT) isn't used anymore. TBR=phajdan.jr@chromium.org,abodenha@chromium.org,tim@chromium.org BUG=none Review URL: https://chromiumcodereview.appspot.com/11365112 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166706 0039d316-1c4b-4281-b951-d872f2087c98
* Moved JsonPrefStore to use SequencedWorkerPool instead of FILE thread. The ↵zelidrag@chromium.org2012-11-081-23/+27
| | | | | | | | | | | pool also ensures that the same file requests are written in order received and that they block on shutdown. BUG=153367 TEST=existing unit/browser tests Review URL: https://codereview.chromium.org/11027070 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166603 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 165062 - We believe this change broke startup_testsnsylvain@chromium.org2012-11-011-27/+23
| | | | | | | | | | | | | | | | Original description: Moved JsonPrefStore to use SequencedWorkerPool instead of FILE thread. The pool also ensures that the same file requests are written in order received and that they block on shutdown. BUG=153367 TEST=existing unit/browser tests Review URL: https://codereview.chromium.org/11027070 TBR=zelidrag@chromium.org Review URL: https://codereview.chromium.org/11312046 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165492 0039d316-1c4b-4281-b951-d872f2087c98
* Moved JsonPrefStore to use SequencedWorkerPool instead of FILE thread. The ↵zelidrag@chromium.org2012-10-301-23/+27
| | | | | | | | | | | pool also ensures that the same file requests are written in order received and that they block on shutdown. BUG=153367 TEST=existing unit/browser tests Review URL: https://codereview.chromium.org/11027070 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@165062 0039d316-1c4b-4281-b951-d872f2087c98
* base: Update calls froms RunAllPending() to RunUntilIdle().tfarina@chromium.org2012-10-301-4/+4
| | | | | | | | | | | BUG=131220 TEST=base_unittests R=willchan@chromium.org Review URL: https://chromiumcodereview.appspot.com/11339020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@164802 0039d316-1c4b-4281-b951-d872f2087c98
* Move the bits of Prefs where production code has only trivially easyjoi@chromium.org2012-10-221-0/+293
to break dependencies back to Chrome. This leaves the following in chrome/ for now, which will move later: - PrefService, to move once sync dependencies and dependencies on Chrome-specific pref stores are externalized. - PrefNotifierImpl and PrefObserverMock, to move once NotificationSource dependency is broken. - PrefValueStore, to move once PrefModelAssociatior dependency is externalized. - ScopedUserPrefUpdate, to move once PrefService moves. TBR=ben@chromium.org BUG=155525 Review URL: https://chromiumcodereview.appspot.com/11243002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@163354 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-05-13 17:46:06 +0000