5

Is the notion/concept of "immediate events" something that exists in Javascript implementations?

Background

In this this answer to the question "Is javascript guaranteed to be single-threaded?" the auther mentions something he refers to as immediate events. Such an immediate event is a callback function (i.e. to something like the "resize" of the browser window window.onresize = callbackfunc; ), which is executed while some other Javascript code has not yet "finished", because for instace it is blocked (i.e. alert("alert");).

Let me clarify with an example:

// (1) Setup a "immediate event" (a callback for "resize");
window.onresize = function(){ console.log("log resize"); };

// (2) Run some code which contains a blocking alert()
console.log("log A");
console.log("log B");
alert("alert");
console.log("log C");

(As a jsfiddle http://jsfiddle.net/rj25m/5/)

Outputs of the script above for different cases/scenario:

Case 1 (No resizing takes place)

log A
log B
log C

Case 2 (Windows is resized after alert("alert");)

log A
log B
log C
log resize

Case 3 interesting case (Windows is resized during the alert("alert"); popup)

log A
log B
log resize
log C

NOTICE: Please observe (as mentioned also in the answer mentioned), that on some systems it is not easy to resize the window during there is a modal alert. In MS Windows for instance one needs to temparily reduced the screen revolution to provoke the resize of the window. In other system, most linux, event though there is a alert you can still resize the window.

NOTICE 2: The (Case 3) output I was only able to reproduce in Firefox (used the 26.0 version). IE and Chrome did not seem to "support" those "immediate events" and it seems that there the resize event was noticed but scheduled to run after the completion of the block which was blocked by the alert("alert").

Case 4 (like Case3, but with Chrome/IE)

log A
log B
log C
log resize

I am confused about the behaviour observed in the Firefox build and the usage of the term "immediate events". I have my doubts if something like this actually exists. This is why I ask here, I expect that somebody is familiar and can answer with reference to the specs of ECMAScript and or reference to the specs of implementations. Looking at the MDN reference to the actual idea of "run to completion" I am inclined to think that the behaviour descriped by immediate events is nothing desired, nothing named and actuallye a Firefox bug. There is some reputation that firefox has some troubles with the alert since they introduced the new (tab modal alert).

I am happy for insight and open to answer comments

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
humanityANDpeace
  • 4,350
  • 3
  • 37
  • 63
  • Look at this thread: https://stackoverflow.com/questions/2734025/is-javascript-guaranteed-to-be-single-threaded/2734311#2734311 – busido Jun 20 '23 at 08:31

1 Answers1

1

There is no thing as "immediate events" in Javascript, normally code will never be interrupted to handle events.

The case with modal popups like alert is the only exception. In some browsers the code in a method can be put "on hold" when you call alert, and there are events happening while the alert is open. Normally there would be no events that needed handling while the alert is open, but obviously you have found an exception.

Normally the "run-to-completion" principle is the rule. Unless you use something like alert or prompt, you can rely on the code being run uninterrupted until you exit your function. Actually nothing happens in the browser while the code is running; there are no page updates, not even GIF animations move while there is Javascript running.

Guffa
  • 687,336
  • 108
  • 737
  • 1,005
  • Thanks, this confirms my doubts I had about the **immediate events**. The run-to-completion is it a ECMAScript spec feature or is it a implementation characteristica? – humanityANDpeace Jan 20 '14 at 17:07
  • @humanityANDpeace: The ECMAScript standard doesn't say anything about threading at all, and has no means for controling concurrency, so the implication is that it's not supposed to be able to handle being multithreaded. Mind that the language was "hacked together" to have something that could do trivial tasks in a browser, not for running web servers and building large singe-page web applications. – Guffa Jan 20 '14 at 22:40
  • Do you have a source for this? I am running into some weird behavior in Mozilla. – flup Mar 25 '14 at 12:59
  • What about the first example in the answer, where the `focus()` method immediately triggered the `blur` handler for the previously-focused element? – Barmar Sep 11 '14 at 10:05
  • @Barmar: I tried the code in that answer ([fiddle](http://jsfiddle.net/Guffa/oyvptsLp/)) and it's only in Chrome that I can see that behaviour. In Firefox the `blur` event doesn't happen at all, so I expect that there is something wrong with the test, but I don't know exactly what. – Guffa Sep 11 '14 at 11:00
  • The answer says that it works differently in IE. That was 4 years ago, maybe FF changed to the IE model since then. – Barmar Sep 11 '14 at 11:02
  • @Barmar: They have most likely changed in some way, but Firefox doesn't work as IE, in IE the blur event happens after the timeout handler has exited. – Guffa Sep 11 '14 at 11:15
  • @Guffa, it could be that under `immediate events` the topic starter assumed `synchronous events` explained pretty detailed [here](http://javascript.info/tutorial/events-and-timing-depth#synchronous-events). – Max Koretskyi Sep 11 '14 at 12:32