Commit Graph

12 Commits

Author SHA1 Message Date
Maria Grazia Alastra
d645d2e812 Bug 331566 - Change idl interfaces to use @throws instead of @return NS_. r=bsmedberg 2013-05-16 08:26:55 -04:00
Jason Duell
deacfc8702 Bug 792920 - clarify thread-safe use of nsITimer v2. r=bz DONTBUILD 2013-04-08 15:20:00 -07:00
Jason Duell
d787dc2549 Bug 792920 - Update nsITimer.idl comments re: off main-thread use. r=mcmanus DONTBUILD 2013-04-04 11:36:07 -07:00
Jason Duell
164eb37294 Bug 778296 (previous commit was empty!) - Add comment about thread-safety to nsITimer DONTBUILD. r=bz 2012-07-27 13:58:00 -07:00
Gervase Markham
ca171eec44 Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
Serge Gautherie
6178112fa0 Bug 740769. (Bv1) Convert test_bug325418.js file to LF end-of-lines, Fix nsITimer.idl documentation. r=bzbarsky.
DONTBUILD.
2012-04-10 04:32:19 +02:00
wfernandom2004@gmail.com
5963fbfd3b Bug 338583, implement EventSource, r=smaug,Ms2ger
--HG--
extra : rebase_source : 9dd6bbbc0d714fbafb2ed115c40cf7210b663b6a
2011-05-22 22:30:07 +01:00
Boris Zbarsky
dd94d998a3 Bug 650379. Add a new XPCOM timer type that is like TYPE_REPEATING_PRECISE but does not swamp the event queue if the callback takes longer than the timer interval to run. r=cjones, sr=brendan
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.
2011-04-28 19:33:52 -04:00
Nickolay_Ponomarev
1820b09634 Bug 472258 - Reinitializing one-shot timers by resetting delay (->SetDelay) doesn't work anymore - fix callers; r+sr=bzbarsky 2009-02-03 15:42:21 +01:00
Ben Turner
42fd53c413 Bug 443877 - "Need a way to point timers at a different event target". r=bsmedberg. 2008-07-24 10:20:33 -07:00
mozilla.BenB@bucksch.org
6868cb30a4 Make nsITimerCallback a [function], to allow JS to pass a function object instead of this interface Bug 430305 r/sr/a=shaver 2008-04-23 10:42:58 -07:00
hg@mozilla.com
465265d0d4 Free the (distributed) Lizard! Automatic merge from CVS: Module mozilla: tag HG_REPO_INITIAL_IMPORT at 22 Mar 2007 10:30 PDT, 2007-03-22 10:30:00 -07:00