Currently the RefreshDriver *mostly* returns a monotonically increasing time. However, when the put it under test control, advance the time, then restore the refresh driver from test control the resulting time ends up going backwards. This means that any code that uses the refresh driver cannot assume monotonically increasing times. In bug 972199 I tried to fix this by making the refresh driver accumulate an extra count representing the amount of time it had been advanced (see the obsolete patches in bug 972199 comment 6 onwards). The tricky part is this same handling needs to be applied to the compositor *and* the accumulated advance needs to be synchronized between the main thread and the compositor. As a result, in bug 972199 we just went with a more localized solution to the problem. However, I've since tripped up on this a few more times. At some point it's probably going to be worth the effort to implement this and prevent further surprises.