Follow the Click
One pointer event, from the input hardware to the frame the user finally sees. The interesting part is not the handler — it is everything the browser has to do after your handler returns, and the several places that work can be delayed by something you did somewhere else.
A click that feels instant and a click that feels broken run exactly the same code. The difference is whether the main thread was free to run it, whether the work it triggered fit in a frame, and whether the browser got a rendering opportunity before the user decided nothing had happened and clicked again.
- One layer deeper
Hit testing uses the most recently completed layout, not the frame currently being produced. If something moved between the paint the user aimed at and the moment their finger landed, the click is delivered to whatever now occupies that position — which is why a late-loading banner is not merely annoying, it is a mis-click generator.
What can go wrong here- — Content shifts between paint and tap, so the click lands on the element that took the old one's place.
- — A transparent overlay left mounted after a dialog closes swallows every click with no visual evidence.
- — The interaction exists only for a pointer, so a keyboard, a switch or a screen reader has no way to reach it at all.
The other two walks
Same page, different question. Each one crosses the loop at a different point.