Fix black background when locking with fullscreen window:

base/time.h

 // Copyright (c) 2012 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.
 
 // Time represents an absolute point in time, internally represented as
 // microseconds (s/1,000,000) since the Windows epoch (1601-01-01 00:00:00 UTC)
 // (See http://crbug.com/14734).  System-dependent clock interface routines are
 // defined in time_PLATFORM.cc.
 //
 // TimeDelta represents a duration of time, internally represented in
@@ skipping 620 matching lines @@
 #if defined(OS_WIN)
   typedef DWORD (*TickFunctionType)(void);
   static TickFunctionType SetMockTickFunction(TickFunctionType ticker);
 #endif
 };
 
 inline TimeTicks TimeDelta::operator+(TimeTicks t) const {
   return TimeTicks(t.ticks_ + delta_);
 }
 
+// TimeFactory ----------------------------------------------------------------
+
+class BASE_EXPORT TimeFactory {
+ public:
+  virtual Time TimeNow() = 0;
+  virtual TimeTicks TimeTicksNow() = 0;
+  virtual TimeTicks TimeTicksHighResNow() = 0;
+
+  static TimeFactory* instance() { return instance_; }
+
+ protected:
+  static TimeFactory* instance_;

[akalin, 2012/12/12 00:58:12]

This scares me.  Overriding time globally seems like a blunt instrument and may
have unintended consequences (since a lot of stuff assumes that TimeTicks
increase monotonically, etc.).  Is there a way to simply dep-inject TimeFactory
into the class that needs it?  Or at least separate out the singleton instance
stuff from the interface itself?

Also, I feel like adding a TimeFactory interface in base/ is a pretty big change
-- I wonder if it would be better to do it in a separate CL, especially since it
seems like there's some time pressure to get this CL in.  Thoughts?

[Denis Kuznetsov (DE-MUC), 2012/12/12 19:20:13]

That was my initial approach, but Scott insisted that we should mock
Time/TimeTicks (https://chromiumcodereview.appspot.com/11453012/#msg7 and
https://chromiumcodereview.appspot.com/11453012/#msg11).

I've added docs in implementation that would guide how to use mocked timer
properly, made mock object to preempt current time on creation, and added DCHECK
so that time can not be moved backwards - the only case when time can decrease
now is removal of mock time.
Also, mocking object should not persist across tests, so all changes in time are
test-local.
 
Core change of this CL changes the way some callbacks are called (animation
finish VS timer trigger). So there is a need to advance animations in a some
way. There is a way to make this testing without mocking TimeTicks::Now(), but
it results in a flakiness caused by ocassional off-by-one changes in
TimeTicks::Now() result between several places.

So I see three options: disabling tests, introducing flakiness into tests, and
mocking time.

[sky, 2012/12/12 20:42:23]

I prefer mocking at a central place. It means supporting code doesn't need to
change to take a Clock object. Additionally injecting a Clock like object in all
places a particular code path calls into can be tedious and require exposing
objects you might not normally expose.

That said, I'm not an owner here and leave the decision to Brett (or other
base/OWNERS).
Agreed. Splitting patches into smaller chunks with fewer reviewers is always a
good thing.

+};
+
 }  // namespace base
 
 #endif  // BASE_TIME_H_