Adding UMA stats.

chrome/browser/password_manager/password_manager.cc

Index: chrome/browser/password_manager/password_manager.cc
diff --git a/chrome/browser/password_manager/password_manager.cc b/chrome/browser/password_manager/password_manager.cc
index 7885d2196f61186cc4e0b259c66df86dbb61658c..bb14689863c57479a5384036dbb6c7eec86bd969 100644
--- a/chrome/browser/password_manager/password_manager.cc
+++ b/chrome/browser/password_manager/password_manager.cc
@@ -4,6 +4,7 @@
 
 #include "chrome/browser/password_manager/password_manager.h"
 
+#include "base/metrics/histogram.h"
 #include "base/threading/platform_thread.h"
 #include "base/utf_string_conversions.h"
 #include "chrome/browser/password_manager/password_form_manager.h"
@@ -239,6 +240,8 @@ void PasswordManager::OnPasswordFormsRendered(
   // given consent, either through previously accepting the infobar or by having
   // the browser generate the password.
   provisional_save_manager_->SubmitPassed();
+  if (provisional_save_manager_->HasGeneratedPassword())
+    UMA_HISTOGRAM_COUNTS("PasswordGeneration.Submitted", 1);

[Ilya Sherman, 2012/07/19 23:29:08]

Keep in mind that this will have the same bias as if you were logging to a
single histogram, so you'll still need to be aware of this bias when analyzing
the uploaded data.

If you want to be able to compare the stats gathered in the renderer to this
one, you will probably want to send messages from the renderer process to the
browser process as the events occur, and log to a single histogram in the
browser process.  If you're not too worried about the bias, you can leave the
code as it is, but please add a note about this potential for bias to the
histogram description (which you'll create in a separate CL, as part of adding
the histogram to the master XML file).

   if (provisional_save_manager_->IsNewLogin() &&
       !provisional_save_manager_->HasGeneratedPassword()) {
     delegate_->AddSavePasswordInfoBarIfPermitted(