From a click to our listener

A USB mouse in boot protocol sends a short report every time something changes. Byte 0 holds the buttons, one bit each; bytes 1 and 2 are the X and Y movement. The kernel's driver gets the report in an interrupt handler and turns each bit into a call to input_report_key. Then input_sync marks the end of one consistent report.

The evdev handler copies each of those values into a struct input_event in a per-reader ring buffer and wakes anyone reading /dev/input/eventN. On desktop Linux the reader is the window system (a Wayland compositor through libinput, or the X server), which sends Chrome a pointer-button message for its window. On ChromeOS, Chrome reads evdev itself; that is the EventConverterEvdevImpl code below, the same input_event structs going into Chrome's ui::Event system.

The window system's event reaches Chrome's browser process as a ui::MouseEvent on the window (Aura on Linux and Windows). RenderWidgetHostViewEventHandler::OnMouseEvent converts it to a blink::WebMouseEvent and asks the input event router where it should go. With site isolation a page can contain iframes from other sites, each drawn by a different renderer process, so the router first hit-tests surfaces: the regions each renderer's frames cover, as reported to the GPU process (Viz). With only one renderer on screen it skips that work, as the code shows.

Then RenderWidgetHostImpl::ForwardMouseEvent hands it to the input router, which sends it over Mojo with WidgetInputHandler::DispatchEvent. A press is blocking: the browser keeps it in flight until the renderer replies with whether a listener consumed it. That reply is how the browser knows, for example, whether to start a drag or show a context menu.

Mojo delivers DispatchEvent on the renderer's compositor thread, not the main thread. That thread can handle some input alone: it can scroll a layer while the main thread is busy, unless a non-passive wheel or touch listener might cancel the scroll. A mouse press is not something it can handle, so MainThreadEventQueue queues it for CrRendererMain.

The queue treats event types differently. Mouse moves, wheel and touch moves are rAF-aligned: they are held and coalesced until the next frame begins, so a mouse that reports 1,000 times a second does not run our mousemove listener 1,000 times. A press or release is not in that list, so it is posted to the main thread right away.

EventHandler::HandleMousePressEvent asks for the target with GetMouseEventTarget, which ends in LayoutView::HitTest. The question "what is under this point?" must give the answer we see, so hit testing follows the same order as painting, in reverse: whatever was painted last is on top and is tested first.

PaintLayer::HitTestLayer does this per stacking context: first the children with positive z-index (highest first), then the normal-flow and z-index: 0/auto children, then the layer's own foreground, then negative z-index children, then its own background. A box is skipped when the point is outside it, when an ancestor's overflow clips it there, or when it has pointer-events: none or visibility: hidden. Both of those are inherited, and a descendant can set them back.

Each line is one absolutely positioned box: box ID LEFT TOP WIDTH HEIGHT, then optional in PARENT, z=N, pe=none or pe=auto, hidden or visible, and clip (overflow: hidden). The stage is a 360 × 240 stacking context. Click anywhere on it, or type a point and press Test point. The model walks its painting order from the front; this browser answers with document.elementFromPoint on the very same boxes.

For a press, Blink fires a pointerdown (Pointer Events) and then the compatibility mousedown, both at the hit element. If the element can take focus, focus moves next (focus, focusin). For a release it fires pointerup, mouseup, and then possibly a click.

The click is not simply "the element under the release". MouseEventManager::DispatchMouseClickIfNeeded takes the element that got the mousedown and the element under the mouseup and sends the click to their common ancestor. We captured that: press on #a, drag to #b, release, and the click landed on #card, which contains both. That is why dragging off a button before releasing does not click it.

Dispatch starts by building the event path: the target, each ancestor, the document and the window. It is fixed now; moving the target to another place during dispatch does not change who is visited. Then DispatchEventAtCapturing walks the path from the window down and runs capture listeners; at the target it runs only the target's capture listeners. DispatchEventAtBubbling walks back up: the target's other listeners first, then, if the event bubbles, each ancestor's non-capture listeners.

At each target, FireEventListeners takes a snapshot of that target's listener list. A listener added now does not run in this pass. A listener removed now is skipped, because it is marked removed. A once listener is removed just before it runs. stopPropagation() lets the rest of the current target's listeners run; stopImmediatePropagation() stops at once. A passive listener's preventDefault() is ignored.

A program is a tree of tags with ids, some listen lines, and one dispatch line. Listener options: capture, once, passive. Actions after a colon: stop, stopNow (stopImmediatePropagation), prevent, micro (queue a microtask), add TARGET TYPE [capture], remove L2. Listeners are named L1, L2, … in order, and every listener logs itself when it runs.

dispatch click at btn by user is a real click. by script is dispatchEvent from a script; add nobubble or nocancel for an event that does not bubble or cannot be cancelled. Check in this browser runs the same program with real listeners: a script dispatch runs immediately, and for a user program we click the dashed box ourselves.

A listener is called through JSBasedEventListener::Invoke, which, through the generated callback bindings, ends in V8ScriptRunner::CallFunction. That function opens a V8RunMicrotasksScope around the call. When the scope closes, V8 performs a microtask checkpoint, but only if no other script is still running underneath: ShouldPerformCheckpoint requires the scope depth to be back at zero.

For a real click, the listener was called from C++ input handling with an empty JavaScript stack, so the depth is zero and the microtasks queued by that listener run before the next listener. For btn.click() our own script is still on the stack, the depth stays above zero, and all the microtasks wait until that script finishes. The HTML standard says the same thing in "clean up after running script".

We recorded a trace while Playwright pressed and released the mouse over the button. Playwright's mouse goes into Chrome through the DevTools protocol and enters the normal input path at the browser process's RenderWidgetHostImpl::ForwardMouseEvent, the same place an event from the window system arrives. Everything below is a real trace event.

Five questions in the style of a web systems or operating systems exam. Write our answer first, then open the model answer and mark ourselves honestly. Answers that list listener orders were produced by the dispatch model and checked with the lab's real-browser check.