cc: Allow the main thread to cancel commits

cc/scheduler/scheduler_unittest.cc

Index: cc/scheduler/scheduler_unittest.cc
diff --git a/cc/scheduler/scheduler_unittest.cc b/cc/scheduler/scheduler_unittest.cc
index 2824510a8685da3910430e261d39c022022e53c0..4a3fd4faf7f74db260d0199222e9a07f5253b496 100644
--- a/cc/scheduler/scheduler_unittest.cc
+++ b/cc/scheduler/scheduler_unittest.cc
@@ -378,11 +378,17 @@ TEST(SchedulerTest, VisibilitySwitchWithTextureAcquisition) {
                        client);
   client.Reset();
 
+  // Already sent a begin frame on this current frame, so wait.
+  scheduler->SetVisible(true);
+  EXPECT_EQ(0, client.num_actions_());
+  client.Reset();
+
   // Regaining visibility with textures acquired by main thread while
   // compositor is waiting for first draw should result in a request
   // for a new frame in order to escape a deadlock.
-  scheduler->SetVisible(true);
-  EXPECT_SINGLE_ACTION("ScheduledActionSendBeginFrameToMainThread", client);
+  scheduler->BeginFrame(BeginFrameArgs::CreateForTesting());

[danakj, 2013/07/17 20:53:24]

I'm having trouble convincing myself that we will cause this BeginFrame to
happen here. Why wasn't there a SetNeedsBeginFrameOnImplThread before this after
SetVisible(true)?

[enne (OOO), 2013/07/18 17:36:37]

Different begin frames.  SetNeedsBeginFrameOnImplThread is set in response to
scheduler->BeginFrame above.  Because that didn't happen in the old code, there
was no need for it.

+  EXPECT_ACTION("ScheduledActionSendBeginFrameToMainThread", client, 0, 2);
+  EXPECT_ACTION("SetNeedsBeginFrameOnImplThread", client, 1, 2);
   client.Reset();
 }