Are DOM Single Threaded events always running?

Question

So, I answered a question recently, and the OP asked if I could add the following about DOM events to my answer:

Perhaps you can also add to your answer that not only are they executed at first, but the subsequent event is blocked until the first is completed.

Ok, can I add this? Do I know that with events, the DOM will fire one event at a time and wait for the previous one to complete before the next launch?

As far as I know, this is always the case in JavaScript browser?

Finding a definitive answer to this has been surprisingly difficult so far, I expected yes, but I just can't find it.

---

Clarification . I am not asking about adding other asynchronous handlers inside handlers or calling setTimeout or workers and the like. All I ask is is the execution order of the event handler guaranteed, and the next next only starts from the previous end? A good answer would be from a reliable source (preferably a specification). There's nothing here.

Answer 1

Yes and no , all JS works in one thread, except for web workers who do not have access to the DOM. http://dev.opera.com/articles/view/timing-and-synchronization-in-javascript/

Here is some relevant information on this page.

All the functions of the event handler are executed sequentially, and each event is processed completely (including bubbles through the DOM and the execution of the default action), before the next event is processed.

However, later on this page they mention

Race conditions

Each window (and frame) has its own event queue. In Opera, each window has its own JavaScript stream. This includes windows in the iframe. The consequence of this is that event handlers triggered from different frames can be executed simultaneously. If these simultaneous scripts modify the general data (for example, the properties in the upper window), we have the possibility of race conditions.

Events are all placed in the event queue, and all event processing occurs in the same thread. Along with all asynchronous callbacks like XHR and setTimeout .

Beware of nested events, as many methods will execute if you fire an event, and they can change the global state. Example http://jsfiddle.net/rpxZ4/

 $('#d1').click(function(){ alert('before '); $('#d2').trigger('click'); $('#d3').trigger('click'); alert('after '); }); $('#d2, #d3').click(function() { alert('clicked ' +this.id); }); 

Here are Opera's suggestions for working with timing

• You do not have long scripts.
• Do not use synchronous XMLHttpRequests.
• Do not allow scripts initiated from different frames to manage the same global state.
• Do not use alerts for debugging, as they can completely change the program logic.

Answer 2

Well, it really depends on what you do in your handler and how you determine the moment of the first handler?

For example, if you only perform synchronization operations in eventHandler1, then you are sure that eventHandler2 will not be triggered until eventHandler1 completes. the reason is javascript is single threaded.

But imagine this scenario: press button1, fires eventHandler1, which actually makes an ajax request. in this scenario, what do you actually consider the "end of eventHandler1"? if this is the moment when the ajax request is returned, then, of course, eventHandler2 will start execution (and possible completion) before eventHandler1 completes.

In short: whenever you perform operations only for synchronization> the order is guaranteed.

Added from comments:

http://www.w3.org/TR/DOM-Level-3-Events/#sync-async , for example: "Each event in this virtual queue should be delayed until the previous event completes its distribution behavior, or canceled. "

---

So, now we return to the question "what events are we talking about"? As mentioned earlier: if these are asynchronous events, then make sure the order is not guaranteed. But the original dilemma was related to the click event and that it is not asynchronous, but synchronized. And the documentation for synchronization events clearly states: Events that are synchronous ("synchronization events") should be processed as if they were in a virtual queue in the first model in the first order, ordered by a sequence of temporary events, in relation to other events , changes in the DOM and user interaction.

---

yep, no guarantees. now add javascript to a single threaded game and you won’t be able to get them to execute at the same time. but yes, speaking strictly about the DOM - there is no guarantee which one will come first.

---

just another comment ... you might have the exact same DOM, but access it from a multi-threaded Java environment. What then? :), then you must implement your own thread-safe async event handling, because you are no more "protected" by a single-thread environment, as you have with javascript. So the conclusion, as I see it, is that the DOM specifications require that synchronization events be implemented using fifo. to execute asynchronous events, the implementation of the stack / thread depends. in Javascript, this means that 2 handlers cannot intersect, but in Java, for example. does not mean.