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

chrome/renderer/autofill/autofill_agent.cc

 // Copyright (c) 2011 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.
 
 #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"
 #include "chrome/renderer/autofill/password_autofill_manager.h"
 #include "content/renderer/render_view.h"
 #include "grit/generated_resources.h"
 #include "third_party/WebKit/Source/WebKit/chromium/public/WebDocument.h"
 #include "third_party/WebKit/Source/WebKit/chromium/public/WebFormControlElement.h"
 #include "third_party/WebKit/Source/WebKit/chromium/public/WebFrame.h"
 #include "third_party/WebKit/Source/WebKit/chromium/public/WebInputElement.h"
@@ skipping 75 matching lines @@
 
 void AutofillAgent::WillSubmitForm(WebFrame* frame,
                                    const WebFormElement& form) {
   FormData form_data;
   if (FormManager::WebFormElementToFormData(
           form,
           FormManager::REQUIRE_AUTOCOMPLETE,
           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.

   }
 }
 
 void AutofillAgent::FrameTranslated(WebFrame* frame) {
   // The page is translated, so try to extract the form data again.
   DidFinishDocumentLoad(frame);
 }
 
 bool AutofillAgent::InputElementClicked(const WebInputElement& element,
                                         bool was_focused,
@@ skipping 80 matching lines @@
 }
 
 void AutofillAgent::TextFieldDidChangeImpl(const WebInputElement& element) {
   if (password_autofill_manager_->TextDidChangeInTextField(element))
     return;
 
   ShowSuggestions(element, false, true, false);
 
   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,
                                                const WebKeyboardEvent& event) {
   if (password_autofill_manager_->TextFieldHandlingKeyDown(element, event))
     return;
 
   if (event.windowsKeyCode == ui::VKEY_DOWN ||
       event.windowsKeyCode == ui::VKEY_UP)
     ShowSuggestions(element, true, true, true);
@@ skipping 88 matching lines @@
 }
 
 void AutofillAgent::OnFormDataFilled(int query_id,
                                      const webkit_glue::FormData& form) {
   if (!render_view()->webview() || query_id != autofill_query_id_)
     return;
 
   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_);
       Send(new AutofillHostMsg_DidPreviewAutofillFormData(routing_id()));
       break;
     default:
       NOTREACHED();
   }
   autofill_action_ = AUTOFILL_NONE;
 }
@@ skipping 93 matching lines @@
   // WebFormControlElementToFormField does not scrape the DOM for the field
   // label, so find the label here.
   // TODO(isherman): Add form and field identities so we can use the cached form
   // data in FormManager.
   field->label = FormManager::LabelForElement(element);
 
   return true;
 }
 
 }  // namespace autofill