Linux: attempt to write a dummy value to the native password store to get it to

unlock when there are no passwords to migrate into it on startup. This avoids
sometimes choosing the unencrypted store on startup if the native store was
locked, and may be related to bugs 80727, 78675, and 80738.
BUG=80727,78675,80738
TEST=starting linux chrome with locked keyring should always prompt to unlock the first time the password store is used, e.g. by sync or chrome://settings/passwords
Review URL: http://codereview.chromium.org/6902187

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@83773 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 16 insertions, 0 deletions

diff --git a/chrome/browser/password_manager/password_store_x.cc b/chrome/browser/password_manager/password_store_x.cc
index 7c3559f..219ffda 100644
--- a/chrome/browser/password_manager/password_store_x.cc
+++ b/chrome/browser/password_manager/password_store_x.cc
@@ -211,6 +211,22 @@ ssize_t PasswordStoreX::MigrateLogins() {
         break;
       }
     }
+    if (forms.empty()) {
+      // If there's nothing to migrate, then we try to insert a dummy login form
+      // just to force the native store to unlock if it was locked. We delete it
+      // right away if we are successful. If the first operation we try to do is
+      // a read, then in some cases this is just an error rather than an action
+      // that causes the native store to prompt the user to unlock.
+      // TODO(mdm): this means we no longer need the allow_fallback mechanism.
+      // Remove it once this preemptive unlock by write is baked for a while.
+      PasswordForm dummy;
+      dummy.origin = GURL("http://www.example.com/force-keyring-unlock");
+      dummy.signon_realm = "www.example.com";
+      if (backend_->AddLogin(dummy))
+        backend_->RemoveLogin(dummy);
+      else
+        ok = false;
+    }
     if (ok) {
       for (size_t i = 0; i < forms.size(); ++i) {
         // If even one of these calls to RemoveLoginImpl() succeeds, then we