Why does the timeout fire before the "click" event loop is complete on Firefox?

Question

Steps:

run code in the Firefox
wait 5 seconds (important!)
Press OK or Cancel
expect flag == 0, but it is 10.

var flag;

function myFunction(){
    flag = 0 
    console.info("initial", flag);
    setTimeout(function(){
        flag = 10;
    }, 200);
  
    confirm("conf");
   
    alert("should be 0: "+flag);
}

document.getElementById('button').onclick=myFunction;

<button type="button" id="button">Click Me!</button>

I waited for 30 seconds, but still it shows 0. Don't tell me now, it should be 5 seconds only. :P — rajuGT, Nov 16 '15 at 17:30
I think the question is, why does the timeout fire *before the "click" event loop is complete*. — Pointy, Nov 16 '15 at 17:32

score 5 · Accepted Answer · edited May 23 '17 at 12:23

5

Because unlike many browsers, Firefox may allow the JavaScript thread to run other code while the alert, prompt, and confirm modals are showing, suspending the current code. (See end of answer for more on about the "may" in that sentence.) The task where the alert etc. was called is suspended, so the code in that task doesn't proceed, but other tasks are allowed to run.

This means

Timers can get their callback
Ajax completion handlers can run
Etc.

There's never JavaScript running concurrently in two places, but Firefox does let the thread run other tasks while a task is suspended by those modals.

It's an Firefox quirk. I first learned about it right here on Stack Overflow, thanks to bobince.

Why I said "may" allow the JavaScript thread to run: It used to be fairly reliable (olders versions of Firefox). I had no trouble replicating it on Firefox 29 or 38. Firefox 42 seems to make it much less likely, but it does still happen.

I would expect (though I could be wrong) that Mozilla will change this to be in line with other browsers, as one could argue it violates JavaScript's run-to-completion semantics for tasks, and those semantics just got beefed up and clarified by the latest specification.

edited May 23 '17 at 12:23

Community

1
1

answered Nov 16 '15 at 17:32

T.J. Crowder

1,031,962
187
1,923
1,875

New browser version too? I'm not able to reproduce. – rajuGT Nov 16 '15 at 17:35
I can reproduce it on Firefox 42.0 on Windows too. – vitalh Nov 16 '15 at 17:46
@vitalh: Really? I can't (just double-checked). Did you *just* update? – T.J. Crowder Nov 16 '15 at 17:48
@vitalh: I just tried a Windows 8.1 system with Firefox **41**, and got 0, not 10. (My Firefox 42 test was on an older version of Windows.) – T.J. Crowder Nov 16 '15 at 17:52
@t-j-crowder. No. I update immediately after release. – vitalh Nov 16 '15 at 17:52
@vitalh: Bizarre! I just updated that system to 42, and it still gives me 0, not 10. Are you using my test link above? – T.J. Crowder Nov 16 '15 at 17:53
@t-j-crowder. I have checked your test. I still get 10, but sometimes 0.It is unstable. – vitalh Nov 16 '15 at 17:59
@vitalh: What version of Windows? It's completely reliable for me. *Edit* And **just then** I made it happen. – T.J. Crowder Nov 16 '15 at 18:01
@t-j-crowder. Windows 7 x64. – vitalh Nov 16 '15 at 18:06
@vitalh: Yes, as I said above, I made it happen on Firefox 42 as well (Windows 8.1 and then on Linux, too). It seems a lot less likely, but apparently Firefox still has this quirk. – T.J. Crowder Nov 16 '15 at 18:07

score 1 · Answer 2 · answered Nov 16 '15 at 17:38

I tried this in both Firefox and in Chrome. In Firefox I got 10 for a result. In Chrome I got 0 for a result. Likely Firefox and Chrome have different concurrency models when it comes to the confirm function. Firefox is likely running the modal dialog in a separate thread, allowing the setTimeout to continue to run in its own thread (and incrementing the value of flag after 200 milliseconds). Chrome is likely running the modal dialog in the same thread as setTimeout, thus blocking the running of the setTimeout (and not allowing the value of flag to be incremented).

score 0 · Answer 3 · answered Nov 16 '15 at 17:30

0

What? You set flag to 10. Why would you expect it to be 0?

answered Nov 16 '15 at 17:30

Michael Lorton

43,060
26
103
144

How does the timer event happen while the "click" event loop is still active? – Pointy Nov 16 '15 at 17:32
1

*"Why would you expect it to be 0?"* Because on Chrome, IE, and I think Safari, it's `0`. `confirm` is one of the built-in stop-the-world modals. Except on Firefox. – T.J. Crowder Nov 16 '15 at 17:35

Why does the timeout fire before the "click" event loop is complete on Firefox?

3 Answers3