No longer register app window placement preference keys on the fly.

chrome/browser/ui/prefs_migrator.h

Index: chrome/browser/ui/prefs_migrator.h
diff --git a/chrome/browser/ui/prefs_migrator.h b/chrome/browser/ui/prefs_migrator.h
new file mode 100644
index 0000000000000000000000000000000000000000..619ecc5b156c2852e2f308f1c6f82a8063778799
--- /dev/null
+++ b/chrome/browser/ui/prefs_migrator.h
@@ -0,0 +1,39 @@
+// Copyright (c) 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CHROME_BROWSER_UI_PREFS_MIGRATOR_H_
+#define CHROME_BROWSER_UI_PREFS_MIGRATOR_H_
+
+#include "base/memory/scoped_ptr.h"
+#include "base/prefs/pref_store.h"
+#include "base/prefs/writeable_pref_store.h"
+
+// When prefs are loaded from disk this class migrates some previously
+// dynamically registered preferences to their new home in a statically
+// registered dictionary. It can't follow the usual migration pattern because
+// it is migrating preferences that aren't registered at migration time and has
+// to iterate over a raw DictionaryValue looking for keys to migrate.
+//
+// Objects of this class delete themselves after the migration.
+//
+// TODO(dgrogan): Delete this for m41. See http://crbug.com/167256.
+
+class BrowserUIPrefsMigrationObserver : public PrefStore::Observer {

[Bernhard Bauer, 2014/09/10 09:15:47]

Class name and file name should correspond, to make it easier to find where a
class is defined. I would be fine with either class name (PrefsMigrator is nice
and short), although this class only handles migrating some preferences, so
maybe we should qualify the name to reflect that (so, BrowserUIPrefsMigrator as
a middle ground?). 

[gab, 2014/09/10 14:40:04]

+1 on keeping the specific name (BrowserUIPrefsMigrator).

[dgrogan, 2014/09/10 23:09:59]

Done.

[dgrogan, 2014/09/10 23:10:00]

Done.

+ public:
+  explicit BrowserUIPrefsMigrationObserver(
+      scoped_refptr<WriteablePrefStore> pref_store);
+  virtual void OnPrefValueChanged(const std::string& key) OVERRIDE {}

[Bernhard Bauer, 2014/09/10 09:15:47]

Add a blank line before these methods, followed by a comment like
"PrefStore::Observer implementation".

[dgrogan, 2014/09/10 23:09:59]

Done.

+  virtual void OnInitializationCompleted(bool succeeded) OVERRIDE;
+
+ private:
+  friend struct base::DefaultDeleter<BrowserUIPrefsMigrationObserver>;

[gab, 2014/09/10 14:40:04]

Meh.. this also lets anybody own this and delete it from a scoped_ptr, but I
guess that's better than a public destructor... at least it may raise a flag to
a future reader that this isn't your typical ownership model.

[dgrogan, 2014/09/10 23:09:59]

Acknowledged.

+
+  virtual ~BrowserUIPrefsMigrationObserver();
+
+  scoped_refptr<WriteablePrefStore> pref_store_;

[gab, 2014/09/10 14:40:04]

Use a weak pointer here; the PrefStore shouldn't *have* to stay alive until the
read is complete and the migration has been done.

All other post processing steps hooked to the PrefStore do not own it per se.

Actually, a raw pointer should be fine here since OnInitializationCompleted is
called synchronously from the PrefStore itself (which thus must still exist...).

[dgrogan, 2014/09/10 23:09:59]

Switched to raw.

+
+  DISALLOW_COPY_AND_ASSIGN(BrowserUIPrefsMigrationObserver);
+};
+
+#endif  // CHROME_BROWSER_UI_PREFS_MIGRATOR_H_