tree: ef226d95d5f4d5763509ea11c9a6206de617f673 [path history] [tgz]
  1. tracked/
  2. browser_prefs.cc
  3. browser_prefs.h
  4. browser_prefs_unittest.cc
  5. BUILD.gn
  6. chrome_command_line_pref_store.cc
  7. chrome_command_line_pref_store.h
  8. chrome_command_line_pref_store_proxy_unittest.cc
  9. chrome_command_line_pref_store_ssl_manager_unittest.cc
  10. chrome_command_line_pref_store_unittest.cc
  11. chrome_pref_model_associator_client.cc
  12. chrome_pref_model_associator_client.h
  13. chrome_pref_service_factory.cc
  14. chrome_pref_service_factory.h
  15. chrome_pref_service_factory_unittest.cc
  16. chrome_pref_service_unittest.cc
  17. DEPS
  18. DIR_METADATA
  19. incognito_mode_prefs.cc
  20. incognito_mode_prefs.h
  21. incognito_mode_prefs_unittest.cc
  22. OWNERS
  23. persistent_renderer_prefs_manager.cc
  24. persistent_renderer_prefs_manager.h
  25. persistent_renderer_prefs_manager_factory.cc
  26. persistent_renderer_prefs_manager_factory.h
  27. persistent_renderer_prefs_unittest.cc
  28. pref_functional_browsertest.cc
  29. pref_metrics_service.cc
  30. pref_metrics_service.h
  31. pref_service_browsertest.cc
  32. pref_service_incognito_allowlist.cc
  33. pref_service_incognito_allowlist.h
  34. pref_service_syncable_util.cc
  35. pref_service_syncable_util.h
  36. profile_pref_store_manager.cc
  37. profile_pref_store_manager.h
  38. profile_pref_store_manager_unittest.cc
  39. proxy_policy_unittest.cc
  40. README.md
  41. session_startup_pref.cc
  42. session_startup_pref.h
  43. 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)

Adding a new pref

  1. Pick a name that resembles / shares a pref namespace with existing related prefs if possible.
  2. Define a new unique name in a pref_names.cc or pref_names.h file. Either in:
    • chrome/common/pref_names.h -- being careful to put it in the right section (LOCAL STATE versus PROFILE PREFS) and alongside similar prefs (existing ifdefs and/or pref namespaces); or, ideally in:
    • a pref_names.cc local to your component (typically inside a prefs:: C++ namespace nested in your component's namespace)
  3. Add a registration call from