1

Given the single-threadedness of JavaScript, when a synchronous event is fired (for DOM manipulation for example) what happens to the currently executing function block when it is interrupted? How does the browser know where/when to continue execution of the interrupted block? Is there some sort of internal addition of a "pointer" to the event loop? I ask because I'm curious whether other waiting events in the event loop can intervene between the intervention of the synchronous event handler and the continuation of the original function block being executed.

And I am very early in my understanding of asynch events/synchronous events/event loop so if I have this totally wrong please let me know. But my understanding is that synchronous events (nested?) are "fired immediately" and I have seen it happen on jsfiddle with standard cut and paste from tutorials on the subject. I'm just confused as to how JavaScript knows how/where to pick up where it left off since it is so asynch driven.

A snippet:

<input type="button" value="click me">
<input type="text">
 
<script>
  var button = document.body.children[0]
  var text = document.body.children[1]
 
  button.onclick = function() {
    alert('in onclick')
 
    text.focus()
    
    alert('out onclick')
  }
  
  text.onfocus = function() {
    alert('onfocus')
    text.onfocus = null  //(*)
  }
</script>

will produce 'in onclick', 'onfocus', 'out onclick'. The focus is a synchronous event. How does js know to pick back up with next statement after text.focus()? Is it something as simple as the something being done with the frame stack?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Tracy
  • 105
  • 1
  • 11

1 Answers1

1

All the built-in events are asynchronous, but if you were to fire a synchronous event in your code, it would work like any regular function call that returns back once it's done. No event suddenly interrupts executing code - well pressing "stop execution" in developer tools actually does because the compiled code is littered with checks for that in every function and loop.

Esailija
  • 138,174
  • 23
  • 272
  • 326
  • I don't understand what you mean by "built-in" events. Events as simple as focus() are nested and are synchronous. They will interrupt an onclick handler and then return control to the onclick handler. I'll update my original post with this code snippet. – Tracy Jul 30 '13 at 00:06
  • @TracyGentry Well I mean a non-custom event, to make a custom event asynchronous you'd need to use setTimout or similar when calling back the listeners. – Esailija Jul 30 '13 at 00:10
  • @TracyGentry If you mean `.focus()` that is not interruption but how all function calls work, the control goes to the focus function which will call the listners which will return to the focus function and finally back to where you called `.focus()` originally – Esailija Jul 30 '13 at 00:11
  • So at the point that focus() is "fired" are you saying that the event loop is not involved at all. That the focus() call is placed on the frame stack and takes precedence over the event (onclick in my example) being executed? – Tracy Jul 30 '13 at 00:20
  • @TracyGentry yes the event loop is not involved at all, it's just like a regular function call. – Esailija Jul 30 '13 at 00:26
  • So just to be sure I understand...the call (in my code above) "text.focus()" is not really "handled" by "text.onfocus"as an event...onfocus is not really an event handler. Somehow behind the scenes the focus() call is translated (by the browser I suppose?) into a direct function call to the "onfocus" method? – Tracy Jul 30 '13 at 00:54
  • @TracyGentry exactly, you could simply think of the `focus()` method as `focusTheElementInThePage(); if( typeof this.onfocus === "function" ) { this.onfocus(); }` – Esailija Jul 30 '13 at 00:56
  • 1
    Thank you so much! I was having such a disconnect with this. I guess it's obvious now that you've explained it that the synchronous aspect of it is "embedded" within the asynch event being handled (an asynch call that then executes a synchronous call in it's handler method.) – Tracy Jul 30 '13 at 01:01