Events, microtasks & ordering

One click, two possible orders

A click can call the same listeners but produce a different log depending on who started it. A physical click comes from the browser. button.click() comes from JavaScript that is already running.

The central puzzle has two listeners. Each listener logs once and queues one microtask. A real user click logs listener 1, microtask 1, listener 2, microtask 2. A script click logs both listeners before either microtask.

This is not a promise race. It is a call-stack question. Ask one thing first: has the current JavaScript stack become empty yet?

That question also prevents a common debugging mistake. Seeing two logs close together does not prove they ran in one kind of queue. The logs can be adjacent while one is synchronous, one is a microtask, and one is a later task. Label the boundary before you change code.

There is no promise that a product feature should use these low-level boundaries as its business workflow. The lesson explains what the platform does so that a test failure or a surprising console log has a small, concrete explanation. Your application can still choose a clearer sequence.

User input and script dispatch

Start with the script version because it is short and runnable. Lines 3 through 5 register listener 1. Lines 7 through 9 register listener 2. Line 12 calls button.click() from the same script.

1const button = document.querySelector("#order-button");2 3button.addEventListener("click", () => {4  console.log("listener 1");5  queueMicrotask(() => console.log("microtask 1"));6});7 8button.addEventListener("click", () => {9  console.log("listener 2");10  queueMicrotask(() => console.log("microtask 2"));11});12 13button.click();

It prints listener 1, listener 2, microtask 1, microtask 2. Line 12 does not return until both listeners have run. Only after that script call finishes can the microtask queue drain.

Now register the same listeners and click the visible button yourself. The listener bodies are identical. The important change is the browser-created input boundary around the user action.

1const button = document.querySelector("#order-button");2 3button.addEventListener("click", () => {4  console.log("listener 1");5  queueMicrotask(() => console.log("microtask 1"));6});7 8button.addEventListener("click", () => {9  console.log("listener 2");10  queueMicrotask(() => console.log("microtask 2"));11});12 13// Click the visible button with your mouse or keyboard.

Chrome evidence for this lesson shows listener 1, microtask 1, listener 2, microtask 2 for a real page.click(). The test also checks the script order separately. Keep those facts scoped to the event sources being compared.

Registering listener 1 before listener 2 still matters. Both versions preserve that registration order for the listener calls themselves. The difference is where each listener call ends relative to a checkpoint, not a reversal of listener registration.

Keyboard activation is also real user input. It is useful to test it separately when a control has keyboard behavior, but it is not a replacement for understanding the dispatch boundary. This lesson keeps one visible button so the only moving part is where the click came from.

Microtasks between listeners

A microtask does not run in the middle of an active JavaScript stack. It waits until the current call has returned. That one rule is enough to explain both orders.

1const stack = ["script"];2const messages = [];3 4function listener(number) {5  console.log("listener " + number);6  messages.push("microtask " + number);7}8 9listener(1);10listener(2);11while (messages.length) console.log(messages.shift());

Line 4 logs one listener. Line 5 queues its message. Lines 9 and 10 call both listeners before line 11 starts reading queued messages, so the output is listener 1, listener 2, microtask 1, microtask 2.

The browser does not run a microtask simply because one was queued. It runs one at the checkpoint the surrounding dispatch reaches. This is why copying listener code alone does not predict order.

Microtask queue order is first in, first out for the work this lesson queues. If listener 1 queues its microtask before listener 2 queues one, microtask 1 is ahead of microtask 2 once the checkpoint begins. The puzzle is therefore about when draining starts, not which queued item overtakes another.

A long chain of microtasks can keep adding more microtasks. That is useful for small follow-up work, but it can delay a later timer and make an interface less responsive. Use this lesson's rule to understand that result: the browser does not move to the later task until the checkpoint is done.

The click-and-promise puzzle

Use the two replays to slow the puzzle down. They are instrumented teaching models that call the lesson's real order functions. They are not a browser engine debugger.

1const log = [];Run2 3function listener(number) {4  log.push("listener " + number);5  queueMicrotask(() => log.push("microtask " + number));6}7 8// A user input boundary returns before the next listener starts.9listener(1);10// The stack is empty here, so the microtask checkpoint runs.11listener(2);12 13console.log(log);

In the user-input model, listener 1 returns and the checkpoint runs microtask 1 before listener 2 starts. The same listener body is not special; the boundary around it is.

1const log = [];Run2 3function listener(number) {4  log.push("listener " + number);5  queueMicrotask(() => log.push("microtask " + number));6}7 8// Script stays on the stack while it calls both listeners.9listener(1);10listener(2);11// The script call returns; now the microtask checkpoint runs.12 13console.log(log);

In the script model, the call to button.click() keeps the script active while it calls listener 1 and listener 2. The checkpoint appears only after that call returns, so both microtasks wait.

The replay intentionally shows state snapshots instead of pretending to pause Chrome. Each frame comes from a real lesson function and records the visible log or queue at that point. Back and Reset change the replay state, not the browser's actual event loop.

Try saying the two traces aloud. “Listener one returns, checkpoint, listener two returns, checkpoint” is the user model. “Script calls listener one, script calls listener two, script returns, checkpoint” is the synthetic model. A short sentence is often more reliable than a long diagram.

1const button = document.querySelector("#order-button");2 3button.addEventListener("click", () => {4  console.log("listener 1");5  queueMicrotask(() => console.log("microtask 1"));6});7 8button.addEventListener("click", () => {9  console.log("listener 2");10  queueMicrotask(() => console.log("microtask 2"));11});12 13button.click();

Change one input in the playground: the click source. Reset restores the user-input model. The output is deliberately small so you can inspect the exact position of each microtask.

dispatchEvent is synchronous

Synchronous means the method does its listener work before returning to the next line. This is a useful rule for tests and application code because it is deterministic.

1const target = new EventTarget();2target.addEventListener("order", () => console.log("listener"));3 4console.log("before dispatch");5target.dispatchEvent(new Event("order"));6console.log("after dispatch");

Line 4 prints before dispatch. Line 5 calls the listener, which prints listener. Line 6 runs after dispatch returns. The output is before, listener, after.

Do not describe this as “the browser sends an event later.” `dispatchEvent()` is an immediate method call path. It can still queue microtasks, but those wait for the active script stack.

This makes `dispatchEvent()` valuable in unit tests: setup a target, call dispatch, and assert synchronous effects immediately. When the listener starts asynchronous work, write a second assertion after the appropriate promise or timer boundary. That keeps the test honest about what it waits for.

await inside a listener

An async listener starts synchronously. It runs until the first await, then its continuation is scheduled as a microtask. Other synchronous listeners can still run before that continuation.

1const target = new EventTarget();2 3target.addEventListener("order", async () => {4  console.log("listener 1");5  await Promise.resolve();6  console.log("after await");7});8target.addEventListener("order", () => console.log("listener 2"));9 10target.dispatchEvent(new Event("order"));11console.log("after dispatch");

Line 4 prints listener 1. Line 5 reaches await, so the async function pauses. Line 7 runs listener 2 during the same dispatch. Line 10 prints after dispatch, then the microtask prints after await.

This does not mean await makes an event listener run “later” from its first line. It splits one listener into a synchronous first part and a queued continuation.

In a form handler, that split often appears as immediate UI feedback followed by a request result. The first part can disable a button. The continuation can show a result once the promise settles. If a second listener needs to depend on the result, connect the dependency explicitly instead of assuming the continuation runs before it.

Timer versus promise

Promises and timers both delay work, but they use different queues. A promise reaction is a microtask. A zero-delay timer is a later timer task.

1const target = new EventTarget();2 3target.addEventListener("order", () => {4  console.log("listener");5  Promise.resolve().then(() => console.log("promise"));6  setTimeout(() => console.log("timer"), 0);7});8 9target.dispatchEvent(new Event("order"));10console.log("after dispatch");

Line 4 logs listener. Line 5 queues the promise callback. Line 6 queues a timer. After line 9 logs after dispatch, the microtask prints promise, and the later timer prints timer.

The number zero means the timer can become eligible soon. It does not let the timer jump ahead of the current stack or the microtask checkpoint that follows it.

Eligibility is not a clock guarantee. Browser scheduling, nested-timer clamping, background throttling, and other tasks can delay a timer. The stable lesson fact is only the ordering boundary here: a promise reaction queued in this stack runs before the later timer task.

Trusted events

Trusted means the browser created the event from real user interaction. A script can ask an element to click, but it cannot turn that event into trusted user input.

1const button = document.querySelector("#order-button");2button.addEventListener("click", (event) => console.log(event.isTrusted));3 4button.click();

Line 2 prints the event's trust flag. Line 4 calls the click from script, so it prints false. A physical browser click produces an event whose isTrusted is true.

Trust is not an ordering tool and not a security permission you should invent yourself. It tells you something about the event source, which matters when code must distinguish a user gesture from a synthetic test action.

Most application logic should work for both trusted and untrusted events. A test that calls `click()` should still validate a checkout calculation or a selected tab. Reserve trust checks for a requirement that genuinely depends on a user gesture, and test that requirement in a real browser.

Ordering puzzles

Ordering questions become easier when you label every line: current stack, microtask, or later task. Do not start by memorizing a long list of APIs.

A listener called by dispatchEvent() and the line after it are synchronous. Promise reactions and code after an already-resolved await are microtasks. Timers and future physical clicks are later tasks.

This classification is also a debugging method. Add temporary logs that name the boundary, then compare the observed order with the boundary you expected.

Keep the labels modest. “sync start”, “promise checkpoint”, and “timer task” are enough. Names such as “fast” and “slow” are not useful because a microtask can be delayed by active script and a timer can run quickly on an idle page. The queue explains more than a vague speed label.

Practical event code

Real interfaces often have analytics, validation, and UI updates listening for the same event. Do not make correctness depend on whether the event came from a person, a test, or a helper that calls click().

When order matters, make it explicit. Put dependent work in one handler, call a named function in sequence, or await the operation that must finish first. Then a synthetic test and a real interaction share the same business rule.

• Use a single named flow for work that must happen in order.
• Use microtasks for short follow-up work, not as a hidden coordination channel.
• Use timers only when a later task is actually part of the requirement.
• Test trusted-input behavior separately from ordinary application ordering.

Related API lessons explain listener registration, propagation, and custom events: Events introduction, bubbling and capturing, and custom events.

For a production bug report, record the source of the event, the listener names, and the queue boundary before proposing a fix. A one-line reproduction that uses `dispatchEvent()` can reveal whether the bug is in your business sequence or only in a physical-input path.

Common misconceptions

• “All clicks are the same.” Their source can change trust and microtask boundaries.
• “A microtask runs right after I queue it.” It waits for the active stack to empty.
• “`await` pauses every listener.” It pauses only that async function after its first await.
• “Zero-delay timers are immediate.” They run in a later task.
• “`dispatchEvent()` creates user input.” It synchronously creates a synthetic dispatch.

Practice exercises

const target = new EventTarget();
target.addEventListener("order", () => console.log("listener"));
console.log("before");
target.dispatchEvent(new Event("order"));
console.log("after");

const target = new EventTarget();
target.addEventListener("order", async () => {
  console.log("start");
  await Promise.resolve();
  console.log("later");
});
target.dispatchEvent(new Event("order"));
console.log("outside");

const target = new EventTarget();
target.addEventListener("order", () => {
  Promise.resolve().then(() => console.log("promise"));
  setTimeout(() => console.log("timer"), 0);
});
target.dispatchEvent(new Event("order"));
console.log("sync");

Check your understanding

For every answer, identify the event source and then locate the first empty-stack checkpoint.

Key takeaways

• The source of an event can change dispatch boundaries and isTrusted.
• Microtasks run when the current JavaScript stack reaches a checkpoint.
• button.click() and dispatchEvent() call listeners synchronously.
• Code after await and promise reactions are microtasks; timers are later tasks.
• Make business ordering explicit instead of depending on event-source details.

Coming next: Timers in depth, where zero delay, clamping, and timer guarantees get the same careful treatment.