Opera seems to have similar issues.
And our internal implementation is not good enough either: issue #10982

How much does timer coalescing come into play here? The standard Windows 7 timer has a resolution of 15ms, which can be overridden by apps. I can imaging browsers opting into lower resolutions for background tabs, etc as this is critical to conserving battery life.

The test which I saw which failed was called after 92ms for a 100ms timer.

I would be hesitant to try to build stricter timing semantics on top of browser timers and degrade battery perf by doing so.

It is completely ok to wait longer, but not to trigger earlier.
To me that's one of the two basic guarantees a timer should give:

1. never trigger too early.
2. keep the callbacks in order.

If you remove 1, you might as well use a simple Queue in your program...

Yes: that means that we will have to reschedule timers if they happen too early. I sincerely hope that we can fix this correctly in Chrome/Dartium, and only need to do this for other browsers.

I just noticed that most of the affected tests (not timer_isolate_test) already have a safety margin and still fail from time to time :(

Added Library-Async label.

I can't see any flaky status file lines for this issue anymore.

Closing as obsolete.