Add testRunner.runIdleTasks() to force idle tasks to run.

Add testRunner.runIdleTasks() to force idle tasks to run.

BUG=595152
R=skyostil@chromium.org,rmcilroy@chromium.org,esprehn@chromium.org

Committed: https://crrev.com/69e3ac0fc139d5e7271987c39b6126f3525d88d9
Cr-Commit-Position: refs/heads/master@{#386563}

[szager1, 2016-03-23 22:53:59]

This is my first time working with non-blink chromium code, so this patch is
probably a horrid mess, but it works for me :)

[szager1, 2016-03-23 22:55:13]

https://codereview.chromium.org/1832673002/diff/1/components/scheduler/child/...
File components/scheduler/child/idle_helper.cc (right):

https://codereview.chromium.org/1832673002/diff/1/components/scheduler/child/...
components/scheduler/child/idle_helper.cc:531: new
IdleTaskObserverForTesting(idle_queue_, helper_, callback);
This is intentional; the instance gets deleted in
IdleTaskObserverForTesting::DidProcessTask.

[szager1, 2016-03-24 15:10:18]

Any thoughts on this while our working hours overlap?

[szager1, 2016-03-24 16:42:06]

Description was changed from

==========
Add testRunner.runIdleTasks() to force idle tasks to run.

BUG=595152
R=skyostil@chromium.org,rmcilroy@chromium.org,esprehn@chromium.org
==========

to

==========
Add testRunner.runIdleTasks() to force idle tasks to run.

BUG=595152
R=skyostil@chromium.org,rmcilroy@chromium.org,esprehn@chromium.org
==========

[szager1, 2016-03-24 16:42:06]

szager@chromium.org changed reviewers:
+ alexclarke@chromium.org

[szager1, 2016-03-24 16:45:25]

Adding alexclarke@, since sami@ and rmcilroy@ are OOO.

[Sami, 2016-03-29 11:11:18]

Thanks for putting this together. Added a couple of comments.

https://codereview.chromium.org/1832673002/diff/1/components/scheduler/child/...
File components/scheduler/child/idle_helper.cc (right):

https://codereview.chromium.org/1832673002/diff/1/components/scheduler/child/...
components/scheduler/child/idle_helper.cc:531: new
IdleTaskObserverForTesting(idle_queue_, helper_, callback);
On 2016/03/23 22:55:13, szager1 wrote:
> This is intentional; the instance gets deleted in
> IdleTaskObserverForTesting::DidProcessTask.

Instead of using an observer, it might be easier just to post an extra idle task
here which invokes the finished callback. (Actually the caller could do that too
which would reduce some of the plumbing here.)

https://codereview.chromium.org/1832673002/diff/1/components/scheduler/child/...
components/scheduler/child/idle_helper.cc:532:
idle_queue_->SetQueueEnabled(true);
I think one problem here is that IdleHelper might disable the queue while we're
in the middle of running tasks for tests. Maybe we should add a new flag which
tells the helper that we're flushing idle tasks so it knows to avoid messing
with the queue state?

https://codereview.chromium.org/1832673002/diff/1/components/scheduler/child/...
File components/scheduler/child/idle_helper.h (right):

https://codereview.chromium.org/1832673002/diff/1/components/scheduler/child/...
components/scheduler/child/idle_helper.h:128: void RunIdleTasksForTesting(const
base::Closure&);
In this implementation all the idle callbacks are basically getting given a 0 ms
time slice to do their work, right? I think we should make that an explicit
parameter here.

[szager1, 2016-04-06 08:43:17]

https://codereview.chromium.org/1832673002/diff/1/components/scheduler/child/...
File components/scheduler/child/idle_helper.cc (right):

https://codereview.chromium.org/1832673002/diff/1/components/scheduler/child/...
components/scheduler/child/idle_helper.cc:531: new
IdleTaskObserverForTesting(idle_queue_, helper_, callback);
On 2016/03/29 11:11:17, Sami wrote:
> On 2016/03/23 22:55:13, szager1 wrote:
> > This is intentional; the instance gets deleted in
> > IdleTaskObserverForTesting::DidProcessTask.
> 
> Instead of using an observer, it might be easier just to post an extra idle
task
> here which invokes the finished callback. (Actually the caller could do that
too
> which would reduce some of the plumbing here.)

Done; I was able to get rid of all changes to IdleHelper.

https://codereview.chromium.org/1832673002/diff/1/components/scheduler/child/...
components/scheduler/child/idle_helper.cc:532:
idle_queue_->SetQueueEnabled(true);
On 2016/03/29 11:11:17, Sami wrote:
> I think one problem here is that IdleHelper might disable the queue while
we're
> in the middle of running tasks for tests. Maybe we should add a new flag which
> tells the helper that we're flushing idle tasks so it knows to avoid messing
> with the queue state?

Done; added the field in_idle_period_for_testing to struct MainThreadOnly in
RendererSchedulerImp.

https://codereview.chromium.org/1832673002/diff/1/components/scheduler/child/...
File components/scheduler/child/idle_helper.h (right):

https://codereview.chromium.org/1832673002/diff/1/components/scheduler/child/...
components/scheduler/child/idle_helper.h:128: void RunIdleTasksForTesting(const
base::Closure&);
On 2016/03/29 11:11:17, Sami wrote:
> In this implementation all the idle callbacks are basically getting given a 0
ms
> time slice to do their work, right? I think we should make that an explicit
> parameter here.

I changed the implementation to use a regular long idle period, so the tasks
will get a time slice based on the standard long idle period deadline.

[szager1, 2016-04-06 09:07:48]

Added a test, PTAL.

[Sami, 2016-04-06 15:52:38]

Looks great, just minor nits.

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/re...
File components/scheduler/renderer/renderer_scheduler_impl.cc (right):

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/re...
components/scheduler/renderer/renderer_scheduler_impl.cc:32: 
Accidental change?

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/re...
File components/scheduler/renderer/renderer_scheduler_impl.h (right):

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/re...
components/scheduler/renderer/renderer_scheduler_impl.h:109: void
RunIdleTasksForTesting(const base::Closure&);
nit: Please name the parameter (Chromium style doesn't strictly require it but
the code here has names for everything).

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/re...
components/scheduler/renderer/renderer_scheduler_impl.h:190: base::TimeTicks
time_remaining);
Did you mean to remove this parameter?

Also, the callback doesn't seem that useful since it is just synchronously
executed.

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/sc...
File components/scheduler/scheduler.gyp (right):

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/sc...
components/scheduler/scheduler.gyp:57: 'dependencies': [
Do we need BUILD.gn changes too?

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/te...
File components/scheduler/test/renderer_scheduler_test_support.cc (right):

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/te...
components/scheduler/test/renderer_scheduler_test_support.cc:1: // Copyright
2015 The Chromium Authors. All rights reserved.
Ditto.

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/te...
File components/scheduler/test/renderer_scheduler_test_support.h (right):

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/te...
components/scheduler/test/renderer_scheduler_test_support.h:1: // Copyright 2015
The Chromium Authors. All rights reserved.
++year

[szager1, 2016-04-06 17:55:31]

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/re...
File components/scheduler/renderer/renderer_scheduler_impl.cc (right):

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/re...
components/scheduler/renderer/renderer_scheduler_impl.cc:32: 
On 2016/04/06 15:52:37, Sami wrote:
> Accidental change?

Yes, reverted

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/re...
File components/scheduler/renderer/renderer_scheduler_impl.h (right):

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/re...
components/scheduler/renderer/renderer_scheduler_impl.h:109: void
RunIdleTasksForTesting(const base::Closure&);
On 2016/04/06 15:52:37, Sami wrote:
> nit: Please name the parameter (Chromium style doesn't strictly require it but
> the code here has names for everything).

Done.

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/re...
components/scheduler/renderer/renderer_scheduler_impl.h:190: base::TimeTicks
time_remaining);
On 2016/04/06 15:52:37, Sami wrote:
> Did you mean to remove this parameter?
> 
> Also, the callback doesn't seem that useful since it is just synchronously
> executed.

Because this is posted as an idle task, it has to match the IdleTask interface,
which takes a TimeTicks argument.

The callback is useful because it runs *after* the call to EndIdlePeriod().  In
some cases, I'd like to be able to write test code that does not run during idle
time:

requestIdleCallback(testFunction1);
testRunner.runIdleTasks(() => {
  // Guaranteed not to be in idle time.
  requestIdleCallback(testFunction2);
  requestAnimationFrame(() => {
    // Guaranteed that testFunction2 has not yet run.
  });
});

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/sc...
File components/scheduler/scheduler.gyp (right):

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/sc...
components/scheduler/scheduler.gyp:57: 'dependencies': [
On 2016/04/06 15:52:38, Sami wrote:
> Do we need BUILD.gn changes too?

Done.

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/te...
File components/scheduler/test/renderer_scheduler_test_support.cc (right):

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/te...
components/scheduler/test/renderer_scheduler_test_support.cc:1: // Copyright
2015 The Chromium Authors. All rights reserved.
On 2016/04/06 15:52:38, Sami wrote:
> Ditto.

Done.

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/te...
File components/scheduler/test/renderer_scheduler_test_support.h (right):

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/te...
components/scheduler/test/renderer_scheduler_test_support.h:1: // Copyright 2015
The Chromium Authors. All rights reserved.
On 2016/04/06 15:52:38, Sami wrote:
> ++year

Done.

[szager1, 2016-04-06 17:59:02]

szager@chromium.org changed reviewers:
+ dpranke@chromium.org, mkwst@chromium.org, phajdan.jr@chromium.org

[szager1, 2016-04-06 17:59:41]

szager@chromium.org changed reviewers:
- dpranke@chromium.org, mkwst@chromium.org, phajdan.jr@chromium.org

[Sami, 2016-04-06 18:01:58]

Thanks, one more suggestion (sorry for not bringing it up earlier).

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/re...
File components/scheduler/renderer/renderer_scheduler_impl.h (right):

https://codereview.chromium.org/1832673002/diff/40001/components/scheduler/re...
components/scheduler/renderer/renderer_scheduler_impl.h:190: base::TimeTicks
time_remaining);
On 2016/04/06 17:55:30, szager1 wrote:
> On 2016/04/06 15:52:37, Sami wrote:
> > Did you mean to remove this parameter?
> > 
> > Also, the callback doesn't seem that useful since it is just synchronously
> > executed.
> 
> Because this is posted as an idle task, it has to match the IdleTask
interface,
> which takes a TimeTicks argument.
> 
> The callback is useful because it runs *after* the call to EndIdlePeriod(). 
In
> some cases, I'd like to be able to write test code that does not run during
idle
> time:
> 
> requestIdleCallback(testFunction1);
> testRunner.runIdleTasks(() => {
>   // Guaranteed not to be in idle time.
>   requestIdleCallback(testFunction2);
>   requestAnimationFrame(() => {
>     // Guaranteed that testFunction2 has not yet run.
>   });
> });

Ah sorry, I wasn't paying attention while reading this. Somehow I thought this
was part of the public interface.

https://codereview.chromium.org/1832673002/diff/60001/components/scheduler/re...
File components/scheduler/renderer/renderer_scheduler_impl.cc (right):

https://codereview.chromium.org/1832673002/diff/60001/components/scheduler/re...
components/scheduler/renderer/renderer_scheduler_impl.cc:588: void
RendererSchedulerImpl::RunIdleTasksForTesting(
Would you mind moving this into the IdleHelper? I assume we could use this for
idle tasks on worker threads too.

[szager1, 2016-04-06 19:07:10]

https://codereview.chromium.org/1832673002/diff/60001/components/scheduler/re...
File components/scheduler/renderer/renderer_scheduler_impl.cc (right):

https://codereview.chromium.org/1832673002/diff/60001/components/scheduler/re...
components/scheduler/renderer/renderer_scheduler_impl.cc:588: void
RendererSchedulerImpl::RunIdleTasksForTesting(
On 2016/04/06 18:01:58, Sami wrote:
> Would you mind moving this into the IdleHelper? I assume we could use this for
> idle tasks on worker threads too.

Done, PTAL

[rmcilroy, 2016-04-06 23:17:54]

Sorry for the delay looking at this. I like the general approach, a couple of
comments.

https://codereview.chromium.org/1832673002/diff/100001/components/scheduler/r...
File components/scheduler/renderer/renderer_scheduler_impl.cc (right):

https://codereview.chromium.org/1832673002/diff/100001/components/scheduler/r...
components/scheduler/renderer/renderer_scheduler_impl.cc:387: if
(MainThreadOnly().in_idle_period_for_testing)
Is this necessary given you are using a long idle period? The long idle periods
should keep repeating until the compositor says it is about to draw a frame, and
given the compositor doesn't send this signal for the layout tests, we should
always be in an idle periods after you call RunIdleTasksForTesting until
EndIdlePeriodForTesting (e.g., even although each period is only max 50ms, once
we reach the end of that 50ms a new long idle period starts immediately).

https://codereview.chromium.org/1832673002/diff/100001/components/scheduler/r...
components/scheduler/renderer/renderer_scheduler_impl.cc:400: callback.Run();
You probably need to explicitly call EndIdlePeriod here (see above), otherwise
the idle period would continue if there is anything left in the idle queue
(i.e., if the previously run idle callbacks posted called rIC themselves) or go
into the IN_LONG_IDLE_PERIOD_PAUSED state (not ended). See
IdleHelper::UpdateLongIdlePeriodStateAfterIdleTask().

[szager1, 2016-04-06 23:28:39]

https://codereview.chromium.org/1832673002/diff/100001/components/scheduler/r...
File components/scheduler/renderer/renderer_scheduler_impl.cc (right):

https://codereview.chromium.org/1832673002/diff/100001/components/scheduler/r...
components/scheduler/renderer/renderer_scheduler_impl.cc:387: if
(MainThreadOnly().in_idle_period_for_testing)
On 2016/04/06 23:17:53, rmcilroy (Slow) wrote:
> Is this necessary given you are using a long idle period? The long idle
periods
> should keep repeating until the compositor says it is about to draw a frame,
and
> given the compositor doesn't send this signal for the layout tests, we should
> always be in an idle periods after you call RunIdleTasksForTesting until
> EndIdlePeriodForTesting (e.g., even although each period is only max 50ms,
once
> we reach the end of that 50ms a new long idle period starts immediately).

It's my hope that runIdleTasks will also be useful for virtual/threaded/ layout
tests, i.e., it will be deterministic even if the compositor thread jumps in. 
I'm really new to all of this code, so if that seems silly, please let me know.

https://codereview.chromium.org/1832673002/diff/100001/components/scheduler/r...
components/scheduler/renderer/renderer_scheduler_impl.cc:400: callback.Run();
On 2016/04/06 23:17:53, rmcilroy (Slow) wrote:
> You probably need to explicitly call EndIdlePeriod here (see above), otherwise
> the idle period would continue if there is anything left in the idle queue
> (i.e., if the previously run idle callbacks posted called rIC themselves) or
go
> into the IN_LONG_IDLE_PERIOD_PAUSED state (not ended). See
> IdleHelper::UpdateLongIdlePeriodStateAfterIdleTask(). 

This method is only invoked from IdleHelper::EndIdlePeriodForTesting, which
itself calls EndIdlePeriod().  I suppose there's no harm in calling it again
here, but I don't think it's necessary.

[rmcilroy, 2016-04-07 08:48:38]

Looks good, I'll leave Sami to approve.

https://codereview.chromium.org/1832673002/diff/100001/components/scheduler/r...
File components/scheduler/renderer/renderer_scheduler_impl.cc (right):

https://codereview.chromium.org/1832673002/diff/100001/components/scheduler/r...
components/scheduler/renderer/renderer_scheduler_impl.cc:387: if
(MainThreadOnly().in_idle_period_for_testing)
On 2016/04/06 23:28:39, szager1 wrote:
> On 2016/04/06 23:17:53, rmcilroy (Slow) wrote:
> > Is this necessary given you are using a long idle period? The long idle
> periods
> > should keep repeating until the compositor says it is about to draw a frame,
> and
> > given the compositor doesn't send this signal for the layout tests, we
should
> > always be in an idle periods after you call RunIdleTasksForTesting until
> > EndIdlePeriodForTesting (e.g., even although each period is only max 50ms,
> once
> > we reach the end of that 50ms a new long idle period starts immediately).
> 
> It's my hope that runIdleTasks will also be useful for virtual/threaded/
layout
> tests, i.e., it will be deterministic even if the compositor thread jumps in. 
> I'm really new to all of this code, so if that seems silly, please let me
know.

Ahh I see. I guess it doesn't hurt to ensure runIdleTasks works in threaded
mode, although I would prefer that we didn't use it for threaded mode specific
tests to ensure that we are testing real rIC behaviour.

https://codereview.chromium.org/1832673002/diff/100001/components/scheduler/r...
components/scheduler/renderer/renderer_scheduler_impl.cc:400: callback.Run();
On 2016/04/06 23:28:39, szager1 wrote:
> On 2016/04/06 23:17:53, rmcilroy (Slow) wrote:
> > You probably need to explicitly call EndIdlePeriod here (see above),
otherwise
> > the idle period would continue if there is anything left in the idle queue
> > (i.e., if the previously run idle callbacks posted called rIC themselves) or
> go
> > into the IN_LONG_IDLE_PERIOD_PAUSED state (not ended). See
> > IdleHelper::UpdateLongIdlePeriodStateAfterIdleTask(). 
> 
> This method is only invoked from IdleHelper::EndIdlePeriodForTesting, which
> itself calls EndIdlePeriod().  I suppose there's no harm in calling it again
> here, but I don't think it's necessary.

Ahh, missed this. I'm wondering if it would make sense to move all the logic
from IdleHelper here instead - you should be able to do everything you need
(start / end a long idle period and post the end idle period for testing task.
Personally I think that would be cleaner.

[szager1, 2016-04-07 15:59:12]

On 2016/04/07 08:48:38, rmcilroy (Slow) wrote:

> > On 2016/04/06 23:17:53, rmcilroy (Slow) wrote:
> > > You probably need to explicitly call EndIdlePeriod here (see above),
> otherwise
> > > the idle period would continue if there is anything left in the idle queue
> > > (i.e., if the previously run idle callbacks posted called rIC themselves)
or
> > go
> > > into the IN_LONG_IDLE_PERIOD_PAUSED state (not ended). See
> > > IdleHelper::UpdateLongIdlePeriodStateAfterIdleTask(). 
> > 
> > This method is only invoked from IdleHelper::EndIdlePeriodForTesting, which
> > itself calls EndIdlePeriod().  I suppose there's no harm in calling it again
> > here, but I don't think it's necessary.
> 
> Ahh, missed this. I'm wondering if it would make sense to move all the logic
> from IdleHelper here instead - you should be able to do everything you need
> (start / end a long idle period and post the end idle period for testing task.
> Personally I think that would be cleaner.

I actually moved it down into IdleHelper at Sami's request :).

[Sami, 2016-04-08 09:48:14]

On 2016/04/07 15:59:12, szager1 wrote:
> 
> I actually moved it down into IdleHelper at Sami's request :).

Argh, looks like we're giving opposite advice :D Ross and I had a chat and looks
like we prefer keeping the logic in RendererSchedulerImpl like you had
originally in patch set 4 because RendererSchedulerImpl still needs to do things
differently even though IdleHelper has the new functionality. Very sorry about
the churn :P

[szager1, 2016-04-08 19:05:46]

On 2016/04/08 09:48:14, Sami wrote:
> On 2016/04/07 15:59:12, szager1 wrote:
> > 
> > I actually moved it down into IdleHelper at Sami's request :).
> 
> Argh, looks like we're giving opposite advice :D Ross and I had a chat and
looks
> like we prefer keeping the logic in RendererSchedulerImpl like you had
> originally in patch set 4 because RendererSchedulerImpl still needs to do
things
> differently even though IdleHelper has the new functionality. Very sorry about
> the churn :P

No problem, moved it back to RendererSchedulerImpl, PTAL.

[Sami, 2016-04-08 19:21:59]

Thanks, component/scheduler lgtm.

[szager1, 2016-04-08 20:52:32]

szager@chromium.org changed reviewers:
+ mkwst@chromium.org, phajdan.jr@chromium.org

[szager1, 2016-04-08 20:54:39]

Adding OWNERS reviewers:

mkwst@:
  content/shell
  components/test_runner

phajdan.jr@:
  content/public/test
  content/test

[Mike West, 2016-04-11 07:54:00]

LGTM.

[Paweł Hajdan Jr., 2016-04-11 15:55:05]

LGTM

[szager1, 2016-04-11 16:05:12]

The CQ bit was checked by szager@chromium.org

[commit-bot: I haz the power, 2016-04-11 16:05:19]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1832673002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1832673002/120001

[commit-bot: I haz the power, 2016-04-11 16:25:13]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-11 16:25:14]

Try jobs failed on following builders:
  android_compile_dbg on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)

[szager1, 2016-04-11 21:55:27]

The CQ bit was checked by szager@chromium.org

[szager1, 2016-04-11 21:55:27]

The patchset sent to the CQ was uploaded after l-g-t-m from
skyostil@chromium.org, mkwst@chromium.org, phajdan.jr@chromium.org
Link to the patchset: https://codereview.chromium.org/1832673002/#ps140001
(title: "rebase")

[commit-bot: I haz the power, 2016-04-11 21:56:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1832673002/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1832673002/140001

[commit-bot: I haz the power, 2016-04-12 01:24:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-12 01:24:38]

Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[szager1, 2016-04-12 01:42:13]

The CQ bit was checked by szager@chromium.org

[commit-bot: I haz the power, 2016-04-12 01:43:26]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1832673002/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1832673002/140001

[commit-bot: I haz the power, 2016-04-12 03:11:43]

Description was changed from

==========
Add testRunner.runIdleTasks() to force idle tasks to run.

BUG=595152
R=skyostil@chromium.org,rmcilroy@chromium.org,esprehn@chromium.org
==========

to

==========
Add testRunner.runIdleTasks() to force idle tasks to run.

BUG=595152
R=skyostil@chromium.org,rmcilroy@chromium.org,esprehn@chromium.org
==========

[commit-bot: I haz the power, 2016-04-12 03:11:44]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2016-04-12 03:12:52]

Description was changed from

==========
Add testRunner.runIdleTasks() to force idle tasks to run.

BUG=595152
R=skyostil@chromium.org,rmcilroy@chromium.org,esprehn@chromium.org
==========

to

==========
Add testRunner.runIdleTasks() to force idle tasks to run.

BUG=595152
R=skyostil@chromium.org,rmcilroy@chromium.org,esprehn@chromium.org

Committed: https://crrev.com/69e3ac0fc139d5e7271987c39b6126f3525d88d9
Cr-Commit-Position: refs/heads/master@{#386563}
==========

[commit-bot: I haz the power, 2016-04-12 03:12:54]

Patchset 8 (id:??) landed as
https://crrev.com/69e3ac0fc139d5e7271987c39b6126f3525d88d9
Cr-Commit-Position: refs/heads/master@{#386563}