See bug 1150420 and bug 1054818. When the screen is locked and we have a high priority wakelock (by virtue of having an ongoing call), performance.now() does not seem to tick until the screen is unlocked again. The easiest way to currently reproduce this to locally apply the changes in bug 1054818 (essentially replace Date.now with performance.now) and then execute the following STR from bug 1150420: 1. MT a call. 2. Press power key to lock screen. Note that you must have the lockscreen enabled. Simply relying on the proximity sensor to blank out the screen will not yield a repro. 3. Wait for some minutes(eg:2min). 4. Wake the device up. [3.Expected Result]: 4. The time-meter should work well. [4.Actual Result]: 4. The time-meter is displayed with wrong time. Some other interesting notes: 1. It's not possible to reproduce this bug with the console cable plugged in 2. You must use the lockscreen to sleep the phone. proximity sensor won't do it.

I think this fits in Core::DOM, based on my |hg blame|ing of the Performance WebIDL file. Tamara, we should get a reduced test case for this. I imagine it would be simple to write a page that requests a high priority wake lock and uses `performance.now()` on a `setInterval()`. Once we have a reduced test case, we should needinfo Kyle (:qDot), though there may be someone better whom he can direct us to.

Note that a reduced test case would also help us see for sure whether it's a problem within the Callscreen, or the System app, or platform code. Something sounds fishy about this only happening when the screen is locked.

All performance.now() does is TimeStamp::Now() followed by subtracting from a fixed timestamp captured during pageload. So is TimeStamp::Now() not ticking? That would be pretty odd, since that's just using clock_gettime...

I'm not able to reproduce this.