Add metrics to measure time elapsed between form load and form submission with or without Autofill.

chrome/renderer/autofill/autofill_agent.cc

Index: chrome/renderer/autofill/autofill_agent.cc
diff --git a/chrome/renderer/autofill/autofill_agent.cc b/chrome/renderer/autofill/autofill_agent.cc
index 9b55fcc8aab6b27f37f315cdeeac960b69a72246..4cf72023f71f542456e1fda822ff1406545c4f4a 100644
--- a/chrome/renderer/autofill/autofill_agent.cc
+++ b/chrome/renderer/autofill/autofill_agent.cc
@@ -5,6 +5,7 @@
 #include "chrome/renderer/autofill/autofill_agent.h"
 
 #include "base/message_loop.h"
+#include "base/time.h"
 #include "base/utf_string_conversions.h"
 #include "chrome/common/autofill_messages.h"
 #include "chrome/common/chrome_constants.h"
@@ -100,7 +101,8 @@ void AutofillAgent::WillSubmitForm(WebFrame* frame,
           static_cast<FormManager::ExtractMask>(
               FormManager::EXTRACT_VALUE | FormManager::EXTRACT_OPTION_TEXT),
           &form_data)) {
-    Send(new AutofillHostMsg_FormSubmitted(routing_id(), form_data));
+    Send(new AutofillHostMsg_FormSubmitted(routing_id(), form_data,
+                                           base::TimeTicks::Now()));

[dhollowa, 2011/08/31 22:40:52]

Wouldn't it be simpler to just track the time on the browser side in the
AutofillManager code?

[Ilya Sherman, 2011/08/31 23:21:32]

Yes, but it would be somewhat less accurate, since IPC calls have no latency
guarantees.

[dhollowa, 2011/08/31 23:42:20]

We're measuring user-time at a many-seconds possibly minutes magnitude.  IPC
latency is tens of milliseconds at worst I'd wager.  So the complexity of
computing it here and plumbing through IPC versus computing Now() in the browser
seems unnecessary.

   }
 }
 
@@ -201,8 +203,10 @@ void AutofillAgent::TextFieldDidChangeImpl(const WebInputElement& element) {
 
   webkit_glue::FormData form;
   webkit_glue::FormField field;
-  if (FindFormAndFieldForNode(element, &form, &field))
-    Send(new AutofillHostMsg_TextFieldDidChange(routing_id(), form, field));
+  if (FindFormAndFieldForNode(element, &form, &field)) {
+    Send(new AutofillHostMsg_TextFieldDidChange(routing_id(), form, field,

[dhollowa, 2011/08/31 22:40:52]

I would think it is just as telling to track the delta between form load and
submit.    Do we really need to start at the first interaction?

[Ilya Sherman, 2011/08/31 23:21:32]

I considered that, but a <form> element being loaded into the DOM does not mean
that it is user visible.  We've seen a number of websites that dynamically
manipulate form visibility.  Moreover, Autofill currently triggers less often
for these forms, because we've really optimized for the case of static forms. 
So, measuring from form load time would bias the metrics in favor of Autofill.

For dynamically shown forms, measuring from the initial interaction time also
better maps on to the number we actually want to measure:  How long does it take
a user to fill a form, with or without Autofill.  If we measure the delta from
form load, all of the metrics will be somewhat inflated.

[dhollowa, 2011/08/31 23:42:20]

But for the dynamic case, we don't flag it as fillable.  So the bias would not
apply.  Also, the first interaction with the form might be with a select-menu so
I'm not sure we're really capturing the first interaction accurately.  Form load
gives a nice predictable start point.

+                                                base::TimeTicks::Now()));
+  }
 }
 
 void AutofillAgent::textFieldDidReceiveKeyDown(const WebInputElement& element,
@@ -311,7 +315,8 @@ void AutofillAgent::OnFormDataFilled(int query_id,
   switch (autofill_action_) {
     case AUTOFILL_FILL:
       form_manager_.FillForm(form, autofill_query_element_);
-      Send(new AutofillHostMsg_DidFillAutofillFormData(routing_id()));
+      Send(new AutofillHostMsg_DidFillAutofillFormData(routing_id(),
+                                                       base::TimeTicks::Now()));
       break;
     case AUTOFILL_PREVIEW:
       form_manager_.PreviewForm(form, autofill_query_element_);