tree: ada35a6c48ff10533580f6020d9631a89f47e4a5 [path history] [tgz]
  1. tracked/
  2. browser_prefs.cc
  3. browser_prefs.h
  4. chrome_command_line_pref_store.cc
  5. chrome_command_line_pref_store.h
  6. chrome_command_line_pref_store_proxy_unittest.cc
  7. chrome_command_line_pref_store_ssl_manager_unittest.cc
  8. chrome_command_line_pref_store_unittest.cc
  9. chrome_pref_model_associator_client.cc
  10. chrome_pref_model_associator_client.h
  11. chrome_pref_service_factory.cc
  12. chrome_pref_service_factory.h
  13. chrome_pref_service_unittest.cc
  14. DEPS
  15. DIR_METADATA
  16. incognito_mode_prefs.cc
  17. incognito_mode_prefs.h
  18. incognito_mode_prefs_unittest.cc
  19. OWNERS
  20. pref_functional_browsertest.cc
  21. pref_metrics_service.cc
  22. pref_metrics_service.h
  23. pref_service_browsertest.cc
  24. pref_service_incognito_allowlist.cc
  25. pref_service_incognito_allowlist.h
  26. pref_service_syncable_util.cc
  27. pref_service_syncable_util.h
  28. profile_pref_store_manager.cc
  29. profile_pref_store_manager.h
  30. profile_pref_store_manager_unittest.cc
  31. proxy_policy_unittest.cc
  32. README.md
  33. session_startup_pref.cc
  34. session_startup_pref.h
  35. session_startup_pref_unittest.cc
chrome/browser/prefs/README.md

Prefs

Prefs is meant to store lightweight state that reflects user preferences (e.g. chrome://settings, position of windows on last exit, etc.). Browser-wide prefs are stored in Local State (g_browser_process->local_state()) and per-profile prefs are stored in Preferences (Profile::GetPrefs()). The base::PrefService API is used to read/write registered prefs. Prefs are saved as JSON and any modification forces serialization of the entire JSON dictionary. The LOSSY_PREF flag can be used when registering a pref to indicate that modifications to it shouldn't schedule a write (in which case the write will be bundled with the next change that does schedule a write or wait until the final write on shutdown; the update is lost in case of a crash).

Prefs are not for:

  • Large collections of data (prefs are loaded and parsed on startup and serialized for writing on the UI thread)
  • Things that change very frequently (every change triggers a write unless using the LOSSY_PREF flag)