5

I know that the callback function of setTimeout, setInterval, setImmediate api is queued in macro task queue.

But, I'm not sure about addEventListener.

Is the callback function of addEventListener is queued in macro task queue?

Check please :D

Byeongin Yoon
  • 3,233
  • 6
  • 26
  • 44
  • 1
    As the name implies, the task queue is a list of tasks that should be executed next. An event listener should be executed whenever the event happens, so it doesn't seem to make sense to have it in that queue. The DOM spec says that it's stored in an event listener list associated with the event target: https://dom.spec.whatwg.org/#eventtarget-event-listener-list – Felix Kling Mar 02 '22 at 15:17
  • @FelixKling Thanks for the reference. Then,, who call the callback function of `addEventListener`? I heard that there are macroTaskQueue, and microTaskQueue, animationFrameQueue in event-loop. If the callbackfunction of `addEventListener` is not queued in macroTaskQueue, how the event loop process the click event? – Byeongin Yoon Mar 02 '22 at 16:31
  • I don't know how browsers process DOM events. It could very will be that a task for processing the event is queued (but note that that wouldn't be the event handler itself). I couldn't find anything in the specs but I also haven't looked that closely. – Felix Kling Mar 02 '22 at 17:23
  • @FelixKling Thank you so much. I also agree with you. Maybe, the Operating System -> Browser Process -> Renderer Process -> queue the task ("dispatch click event to DOM"), not the handler(=listener, callback function) itself. – Byeongin Yoon Mar 02 '22 at 17:26

1 Answers1

5

I know that the callback function of setTimeout, setInterval, setImmediate api is queued in macro task queue.

It's not. What is queued in the timer task-queue is a task. This task's steps will be responsible of executing the callbacks (through the fire an event algo). The callback itself is stored in memory.
For event listeners it's about the same, event callbacks are never queued in a task source, only tasks or microtasks are, and as part of these tasks's steps the events are dispatched and the callbacks are executed.

For instance you can very well have an event fire from a microtask (e.g the slotchange event, but you can also force it yourself with EventTarget#dispatchEvent()), most native events are generally part of task (just search for the phrase to fire an event in the HTML specs for examples), and you have loads of events that don't fire from any tasks nor microtask, but directly as part of the event loop processing, in the update the rendering step.

Kaiido
  • 123,334
  • 13
  • 219
  • 285
  • Thank you so much :D I have a question. You said "The callback itself is stored in memory", what does the memory mean? The Random Access Memory ?. or,, the memory which JS Engine uses ?. Or the callback function is in Execution Context? – Byeongin Yoon Mar 12 '22 at 11:34
  • 1
    Yes probably the memory the JS engine uses (which is allocated in the RAM anyway), though these event callbacks may actually be stored along the DOM object they're associated with, and so I guess an implementation could decide to store some representation of that callback from the DOM engine rather than the JS one, but I don't know, and I doubt this ever matters. However no, it's not "in the Execution Context", but the execution context needs to also be stored so that the callback can be executed from there. – Kaiido Mar 12 '22 at 13:06
  • @kaiido would dispatching an event on a dom element create a new task in the task queue (with the dispatched event callback) to be executed when the call stack is empty? – Fernando Gabrieli Mar 21 '23 at 15:26
  • 1
    @FernandoGabrieli, no, dispatching an event doesn't create a new task, what happens is that lots of native calls to [fire an event](https://dom.spec.whatwg.org/#concept-event-fire) are done from a task that does just that, so the prose reads something like "queue a task to fire an event". But if you call directly `dispatchEvent` no new task is queued, and actually the js callstack isn't even emptied, all the event handlers callbacks are called synchronously on top of the current execution context. – Kaiido Apr 02 '23 at 01:05