Hey all, Just FYI, I've landed a refactoring of how we suspend our timers in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1303167 The short story is that there should be very minimal observable difference. The main changes you might see are: 1) Previously we shifted timers during things like sync xhr. This made it seem like "time stood still" for those timers. If you had a timer in 1 second and did a sync xhr for 0.5 seconds, then the timer would fire 1 second after the sync xhr. Now we don't shift timers and allow "time to pass" during things like sync xhr. So if you have a timer in 1 second and do a sync xhr for 0.5 seconds then the timer will fire 0.5 seconds after the sync xhr. 2) When a modal dialog was closed we used to synchronously run all timers that might have fired during the modal state. We now fire these timers asynchonously. In addition, they may be subject ot the background timer throttling. So these timers will be slightly delayed compared to previously behavior. 3) We now suspend timers in all child windows when a chrome modal dialog is shown. Previously it was possible for content windows to continue to run timers when a chrome modal was open. There was only a single test that this change impacted. This change makes the behavior consistent between content and chrome modal dialogs. The bug has all the gory details, but this change cleans up an error-prone API and a secondary way of stopping timers. We now have a single method for suspending and resuming timers. Please let me know if you run into any problems from these changes. Thanks. Ben _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
