This implements proposal 3 from bug 650379 comment 13. The main difference
between TYPE_REPEATING_PRECISE and TYPE_REPEATING_PRECISE_CAN_SKIP is to not
AddTimer the REPEATING_PRECISE_CAN_SKIP timer until after the callback has run;
this guarantees that no more timer events will be posted until after the
callback finishes executing. A secondary change is to make
REPEATING_PRECISE_CAN_SKIP timers advance their firing time to mDelay from when
PostTimerEvent is called, not mDelay from the old mTimeout. While this arguably
makes them less precise, the alternative is that if a timer is significantly
delayed for some reason (e.g. because the user puts the computer to sleep for a
while) it will then fire a whole bunch of times to "catch up" to where it's
supposed to be, advancing its firing time by mDelay at a time. That seems
undesirable.
An alternate approach would have been to readd the timer from inside
PostTimerEvent, but only if we're not in the middle of firing the timer. That
would allow more precise timers in the case when the callback is not taking too
long, but still handle gracefully the case when the callback is
slow. Unfortunately this falls down if something _else_ is hogging the main
thread event loop (e.g. some other timer has a slow callback, or whatever); in
that case we would post multiple events for the one precise timer while the
event-loop-hogging operation is running. So I don't think we should do that.
on how timers may be canceled, re-initialized, and canceled-then-re-initialized
in nsITimer.idl (181961, r=pavlov, sr=alecf). This helps client code conserve
instances, saving on cycles and malloc/component-manager froth.
