Categories
dom event-loop javascript

Why is setTimeout(fn, 0) sometimes useful?

1032

I’ve recently run into a rather nasty bug, wherein the code was loading a <select> dynamically via JavaScript. This dynamically loaded <select> had a pre-selected value. In IE6, we already had code to fix the selected <option>, because sometimes the <select>‘s selectedIndex value would be out of sync with the selected <option>‘s index attribute, as below:

field.selectedIndex = element.index;

However, this code wasn’t working. Even though the field’s selectedIndex was being set correctly, the wrong index would end up being selected. However, if I stuck an alert() statement in at the right time, the correct option would be selected. Thinking this might be some sort of timing issue, I tried something random that I’d seen in code before:

var wrapFn = (function() {
    var myField = field;
    var myElement = element;

    return function() {
        myField.selectedIndex = myElement.index;
    }
})();
setTimeout(wrapFn, 0);

And this worked!

I’ve got a solution for my problem, but I’m uneasy that I don’t know exactly why this fixes my problem. Does anyone have an official explanation? What browser issue am I avoiding by calling my function “later” using setTimeout()?

5

932

In the question, there existed a race condition between:

  1. The browser’s attempt to initialize the drop-down list, ready to have its selected index updated, and
  2. Your code to set the selected index

Your code was consistently winning this race and attempting to set drop-down selection before the browser was ready, meaning that the bug would appear.

This race existed because JavaScript has a single thread of execution that is shared with page rendering. In effect, running JavaScript blocks the updating of the DOM.

Your workaround was:

setTimeout(callback, 0)

Invoking setTimeout with a callback, and zero as the second argument will schedule the callback to be run asynchronously, after the shortest possible delay – which will be around 10ms when the tab has focus and the JavaScript thread of execution is not busy.

The OP’s solution, therefore was to delay by about 10ms, the setting of the selected index. This gave the browser an opportunity to initialize the DOM, fixing the bug.

Every version of Internet Explorer exhibited quirky behaviors and this kind of workaround was necessary at times. Alternatively it might have been a genuine bug in the OP’s codebase.


See Philip Roberts talk “What the heck is the event loop?” for more thorough explanation.

8

  • 308

    ‘The solution is to “pause” the JavaScript execution to let the rendering threads catch up.’ Not entirely true, what setTimeout does is add a new event to the browser event queue and the rendering engine is already in that queue (not entirely true, but close enough) so it gets executed before the setTimeout event.

    Jun 4, 2012 at 14:30

  • 52

    Yes, that is a much more detailed and much more correct answer. But mine is “correct enough” for people to understand why the trick works.

    – staticsan

    Oct 16, 2013 at 6:36

  • 2

    @DavidMulder, does it means browser parse css and rendering in a different thread from javascript execution thread?

    – jason

    Nov 1, 2013 at 13:34

  • 8

    Nope, they are parsed in principle in the same thread otherwise a few lines of DOM manipulation would trigger reflows all the time which would have an extremely bad influence on the speed of execution.

    Nov 5, 2013 at 13:37

  • 31

    This video is the best explanation to why us setTimeout 0 2014.jsconf.eu/speakers/…

    – davibq

    Nov 9, 2015 at 23:01

709

Preface:

Some of the other answers are correct but don’t actually illustrate what the problem being solved is, so I created this answer to present that detailed illustration.

As such, I am posting a detailed walk-through of what the browser does and how using setTimeout() helps. It looks longish but is actually very simple and straightforward – I just made it very detailed.

UPDATE: I have made a JSFiddle to live-demonstrate the explanation below: http://jsfiddle.net/C2YBE/31/ . Many thanks to @ThangChung for helping to kickstart it.

UPDATE2: Just in case JSFiddle web site dies, or deletes the code, I added the code to this answer at the very end.


DETAILS:

Imagine a web app with a “do something” button and a result div.

The onClick handler for “do something” button calls a function “LongCalc()”, which does 2 things:

  1. Makes a very long calculation (say takes 3 min)

  2. Prints the results of calculation into the result div.

Now, your users start testing this, click “do something” button, and the page sits there doing seemingly nothing for 3 minutes, they get restless, click the button again, wait 1 min, nothing happens, click button again…

The problem is obvious – you want a “Status” DIV, which shows what’s going on. Let’s see how that works.


So you add a “Status” DIV (initially empty), and modify the onclick handler (function LongCalc()) to do 4 things:

  1. Populate the status “Calculating… may take ~3 minutes” into status DIV

  2. Makes a very long calculation (say takes 3 min)

  3. Prints the results of calculation into the result div.

  4. Populate the status “Calculation done” into status DIV

And, you happily give the app to users to re-test.

They come back to you looking very angry. And explain that when they clicked the button, the Status DIV never got updated with “Calculating…” status!!!


You scratch your head, ask around on StackOverflow (or read docs or google), and realize the problem:

The browser places all its “TODO” tasks (both UI tasks and JavaScript commands) resulting from events into a single queue. And unfortunately, re-drawing the “Status” DIV with the new “Calculating…” value is a separate TODO which goes to the end of the queue!

Here’s a breakdown of the events during your user’s test, contents of the queue after each event:

  • Queue: [Empty]
  • Event: Click the button. Queue after event: [Execute OnClick handler(lines 1-4)]
  • Event: Execute first line in OnClick handler (e.g. change Status DIV value). Queue after event: [Execute OnClick handler(lines 2-4), re-draw Status DIV with new "Calculating" value]. Please note that while the DOM changes happen instantaneously, to re-draw the corresponding DOM element you need a new event, triggered by the DOM change, that went at the end of the queue.
  • PROBLEM!!! PROBLEM!!! Details explained below.
  • Event: Execute second line in handler (calculation). Queue after: [Execute OnClick handler(lines 3-4), re-draw Status DIV with "Calculating" value].
  • Event: Execute 3rd line in handler (populate result DIV). Queue after: [Execute OnClick handler(line 4), re-draw Status DIV with "Calculating" value, re-draw result DIV with result].
  • Event: Execute 4th line in handler (populate status DIV with “DONE”). Queue: [Execute OnClick handler, re-draw Status DIV with "Calculating" value, re-draw result DIV with result; re-draw Status DIV with "DONE" value].
  • Event: execute implied return from onclick handler sub. We take the “Execute OnClick handler” off the queue and start executing next item on the queue.
  • NOTE: Since we already finished the calculation, 3 minutes already passed for the user. The re-draw event didn’t happen yet!!!
  • Event: re-draw Status DIV with “Calculating” value. We do the re-draw and take that off the queue.
  • Event: re-draw Result DIV with result value. We do the re-draw and take that off the queue.
  • Event: re-draw Status DIV with “Done” value. We do the re-draw and take that off the queue.
    Sharp-eyed viewers might even notice “Status DIV with “Calculating” value flashing for fraction of a microsecond – AFTER THE CALCULATION FINISHED

So, the underlying problem is that the re-draw event for “Status” DIV is placed on the queue at the end, AFTER the “execute line 2” event which takes 3 minutes, so the actual re-draw doesn’t happen until AFTER the calculation is done.


To the rescue comes the setTimeout(). How does it help? Because by calling long-executing code via setTimeout, you actually create 2 events: setTimeout execution itself, and (due to 0 timeout), separate queue entry for the code being executed.

So, to fix your problem, you modify your onClick handler to be TWO statements (in a new function or just a block within onClick):

  1. Populate the status “Calculating… may take ~3 minutes” into status DIV

  2. Execute setTimeout() with 0 timeout and a call to LongCalc() function.

    LongCalc() function is almost the same as last time but obviously doesn’t have “Calculating…” status DIV update as first step; and instead starts the calculation right away.

So, what does the event sequence and the queue look like now?

  • Queue: [Empty]
  • Event: Click the button. Queue after event: [Execute OnClick handler(status update, setTimeout() call)]
  • Event: Execute first line in OnClick handler (e.g. change Status DIV value). Queue after event: [Execute OnClick handler(which is a setTimeout call), re-draw Status DIV with new "Calculating" value].
  • Event: Execute second line in handler (setTimeout call). Queue after: [re-draw Status DIV with "Calculating" value]. The queue has nothing new in it for 0 more seconds.
  • Event: Alarm from the timeout goes off, 0 seconds later. Queue after: [re-draw Status DIV with "Calculating" value, execute LongCalc (lines 1-3)].
  • Event: re-draw Status DIV with “Calculating” value. Queue after: [execute LongCalc (lines 1-3)]. Please note that this re-draw event might actually happen BEFORE the alarm goes off, which works just as well.

Hooray! The Status DIV just got updated to “Calculating…” before the calculation started!!!



Below is the sample code from the JSFiddle illustrating these examples: http://jsfiddle.net/C2YBE/31/ :

HTML code:

<table border=1>
    <tr><td><button id='do'>Do long calc - bad status!</button></td>
        <td><div id='status'>Not Calculating yet.</div></td>
    </tr>
    <tr><td><button id='do_ok'>Do long calc - good status!</button></td>
        <td><div id='status_ok'>Not Calculating yet.</div></td>
    </tr>
</table>

JavaScript code: (Executed on onDomReady and may require jQuery 1.9)

function long_running(status_div) {

    var result = 0;
    // Use 1000/700/300 limits in Chrome, 
    //    300/100/100 in IE8, 
    //    1000/500/200 in FireFox
    // I have no idea why identical runtimes fail on diff browsers.
    for (var i = 0; i < 1000; i++) {
        for (var j = 0; j < 700; j++) {
            for (var k = 0; k < 300; k++) {
                result = result + i + j + k;
            }
        }
    }
    $(status_div).text('calculation done');
}

// Assign events to buttons
$('#do').on('click', function () {
    $('#status').text('calculating....');
    long_running('#status');
});

$('#do_ok').on('click', function () {
    $('#status_ok').text('calculating....');
    // This works on IE8. Works in Chrome
    // Does NOT work in FireFox 25 with timeout =0 or =1
    // DOES work in FF if you change timeout from 0 to 500
    window.setTimeout(function (){ long_running('#status_ok') }, 0);
});

27

  • 12

    great answer DVK! Here is a gist that illustrates your example gist.github.com/kumikoda/5552511#file-timeout-html

    – kumikoda

    May 10, 2013 at 5:19


  • 4

    Really cool answer, DVK. Just to make easy to imagine, I have put that code to jsfiddle jsfiddle.net/thangchung/LVAaV

    Dec 11, 2013 at 10:09

  • 4

    @ThangChung – I tried to make a better version (2 buttons, one for each case) in JSFiddle. It works as a demo on Chrome and IE but not on FF for some reason – see jsfiddle.net/C2YBE/31. I asked why FF doesn’t work here: stackoverflow.com/questions/20747591/…

    – DVK

    Dec 23, 2013 at 16:50


  • 1

    @DVK “The browser places all its “TODO” tasks (both UI tasks and JavaScript commands) resulting from events into a single queue”. Sir can you please provide the source for this? Imho arent browsers supposed to have different UI ( rendering engine ) and JS threads….no offense intended….just want to learn..

    – bhavya_w

    Dec 18, 2014 at 6:50


  • 1

    @bhavya_w No, everything happens on one thread. This is the reason a long js calculation can block the UI

    Feb 20, 2015 at 12:03

93

Take a look at John Resig’s article about How JavaScript Timers Work. When you set a timeout, it actually queues the asynchronous code until the engine executes the current call stack.