You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It turns out that iOS devices does not always advance the performance.now() during standby. This causes the computed event time to occur after the current performance.now() time.
In this case, I have fixed it by computing an additional systemStandbyOffset, which is added to the returned highResClockOffset in getTimebaseOffset().
Note that this issue is complicated by the fact that touch events apparently has a timestamp that is based on performance.timing.navigationStart + performance.now(), while a click event is a plain Date.now(). Ie. the logic need to handle these two timebases being mixed together.
My testing has been done in an UIWebView on an iOS 11.2.5 device.
It turns out that iOS devices does not always advance the
performance.now()
during standby. This causes the computed event time to occur after the currentperformance.now()
time.In this case, I have fixed it by computing an additional
systemStandbyOffset
, which is added to the returnedhighResClockOffset
ingetTimebaseOffset()
.Note that this issue is complicated by the fact that touch events apparently has a timestamp that is based on
performance.timing.navigationStart + performance.now()
, while aclick
event is a plainDate.now()
. Ie. the logic need to handle these two timebases being mixed together.My testing has been done in an
UIWebView
on an iOS 11.2.5 device.See https://stackoverflow.com/questions/26177087/ios-8-mobile-safari-wrong-timestamp-on-touch-events for a bit of reference.
The text was updated successfully, but these errors were encountered: