See bug 383271. Please cite others bugs like it here, and add FIXME comments citing this bug to any JS cycle breaking that is unnecessary once this bug is fixed. I'll work on this for the next milestone. /be

Explicit breaking of the cycle is common to almost all JS users of nsITimer. Some examples: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in&rev=1.47&mark=513#507 http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/browser/components/sessionstore/src/nsSessionStore.js&rev=1.64#248

Sure, of course -- I remember working with bryner like six years ago on one of those. So turn it around: how many bugs like bug 383271 might there be? Can we do some kind of grep for timer uses from JS that don't break? /be

(In reply to comment #2) > Can we do some kind of grep for timer uses from JS that don't break? Most code I've seen uses timers directly. The only exception I know of, where JS is used to reduce duplication, is GAlarm.

Fixing bug 330128 might fix most of these issues.

Sayrer says we have mitigated otherwise. Disowning, hoping we redo XPCOM timers to use less noisy primitives than condvar-scheduled inter-thread communication. /be