-
Sam McNally authored
The previous approach of encapsulating the pref service from chrome regressed memory. Remove that encapsulation by moving the source of truth back into the browser "service" and using those PrefStores directly from the pref service, bypassing any mojo messages. Remove the control and registration interfaces which are no longer needed since the pref service is directly provided with its PrefStores. Also move the pref service to the UI thread, where the PrefStores already live. Other services may still access prefs via the pref service using the existing sync API (with a local copy of requested prefs), but are responsible for managing the increased memory footprint that could result. Change PersistentPrefStoreImpl to never start a pref read; the embedder is reponsible for ensuring the underlying PersistentPrefStore is either already initialised, or is in the process of being initialised. Change PersistentPrefStoreImpl to always observe the underlying PersistentPrefStore to detect changes originating from inside the embedder. Duplicate the update filtering from the per-connection class to ensure that each client continues to receive each update from other clients exactly once and never be notified about changes it instigated. Bug: 654988 Change-Id: I7eb9e427c9f66d1eb4526d6ea8d9ca6e61c87262 Reviewed-on: https://chromium-review.googlesource.com/554653 Commit-Queue: Sam McNally <sammc@chromium.org> Reviewed-by: David Roger <droger@chromium.org> Reviewed-by: Bernhard Bauer <bauerb@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Robert Sesek <rsesek@chromium.org> Reviewed-by: Noel Gordon <noel@chromium.org> Cr-Commit-Position: refs/heads/master@{#486660}
538fca1e