Add delay to didAssociateFormControlsTimer so it doesn't fire too frequently

chrome/renderer/autofill/autofill_renderer_browsertest.cc

Index: chrome/renderer/autofill/autofill_renderer_browsertest.cc
diff --git a/chrome/renderer/autofill/autofill_renderer_browsertest.cc b/chrome/renderer/autofill/autofill_renderer_browsertest.cc
index 5e54b6b0b979a58373cdafd67f9d876f3fa59467..038c1f4f3dbc7021d7509f911dc231ea90dbe4b9 100644
--- a/chrome/renderer/autofill/autofill_renderer_browsertest.cc
+++ b/chrome/renderer/autofill/autofill_renderer_browsertest.cc
@@ -136,6 +136,7 @@ TEST_F(AutofillRendererTest, SendForms) {
       "document.body.appendChild(newForm);");
   msg_loop_.RunUntilIdle();
 
+  WaitForAutofillDidAssociateFormControl();

[Paweł Hajdan Jr., 2016/06/24 09:13:55]

Isn't this very similar to RunUntilIdle?

I'm wondering - can we have something more windowed, i.e. start listening for
didAssociateFormControls *before* it may be triggered, trigger it, and run the
loop not until idle, but until the listener quits it.

Note that I'm not familiar with blink threads etc. so feel free to just educate
me a bit on that.

[keishi, 2016/06/24 11:35:46]

RunUntilIdle isn't working because it quits before the scheduled timer fires.

I'm not sure how this CL is different from what you're describing.
We calls WaitForAutofillDidAssociateFormControl() before
didAssociateFormControls is expected.
didAssociateFormControls quits the base::RunLoop (in
MockAutofillAgent::didAssociateFormControls)

[Paweł Hajdan Jr., 2016/06/27 18:01:34]

Is it correct to keep RunUntilIdle calls then? I'm not entirely sure what the
_right_ thing is, but explaining things more should get us all on the right
track.
Is the way we do that non-racy? What guarantees whatever triggers
didAssociateFormControls runs after the test calls
WaitForAutofillDidAssociateFormControl? I'm not familiar with this code, but
it's not obviously to me what'd guarantee such call order.
Yup, that part matches my understanding and looks good.

[keishi, 2016/06/28 02:09:18]

Removed RunUntilIdle.
The RenderThread is a mock so Blink main thread seems to be the same as this
test code, so we shouldn't have racing due to threads. I'm not sure if it
happens but I guess if the computer is very slow, the msg_loop_.RunUntilIdle
above could process the didAssociateFormControltimer timer task. Removing
msg_loop_.RunUntilIdle should eliminate that risk.

   message = render_thread_->sink().GetFirstMessageMatching(
       AutofillHostMsg_FormsSeen::ID);
   ASSERT_NE(nullptr, message);
@@ -214,8 +215,10 @@ TEST_F(AutofillRendererTest, DynamicallyAddedUnownedFormElements) {
   ExecuteJavaScriptForTests("AddFields()");
   msg_loop_.RunUntilIdle();
 
+  WaitForAutofillDidAssociateFormControl();
   message = render_thread_->sink().GetFirstMessageMatching(
       AutofillHostMsg_FormsSeen::ID);
+
   ASSERT_NE(nullptr, message);
   AutofillHostMsg_FormsSeen::Read(message, &params);
   forms = std::get<0>(params);