Update text selection on mouseup before dispatching click event

concepts

1. Selection Readout

   Drag-select inside a real <textarea>. The click handler reports the selection range it sees. Compare what gets reported before and after v150 — the v150 output reflects the user's intent, not the pre-mouseup state.

2. Workaround Killer

   Side-by-side: a plain click handler vs. the legacy setTimeout(..., 0) idiom. In v150+ the plain handler is correct on its own — the workaround is dead code.

3. Event Sequence Visualizer

   Click or drag-select inside a textarea and watch a timestamped log of every event fire in order — mousedown, selectionchange, mouseup, then click. A side-by-side comparison shows the selection values read by an immediate click handler versus the old deferred setTimeout workaround — in Chrome 150+ both are identical.

4. Toolbar Builder

   An inline formatting toolbar that opens from the editor's own mouseup and click events. Drag-select text in a textarea and watch the toolbar appear from the immediate click-handler selection read — no deferred setTimeout read needed in Chrome 150+.

   Interactive Textarea Inline toolbar

5. Selection History Log

   A complete event timeline for every mouse interaction in a textarea — mousedown, selectionchange, mouseup, click — each row showing the exact selectionStart/selectionEnd at that instant. The key row to watch: in Chrome 150 the click event sees the same selection as mouseup. A key-finding box auto-detects which ordering you're on.

   Event log Selection API Debugging

6. Code Editor Selection

   A code editor textarea with a toolbar of selection-aware actions — toggle comment, wrap in quotes/backticks, UPPER/lower case — each reading selectionStart/selectionEnd directly in its click handler (no setTimeout). Drag-select any range and click a button. A comparison row shows what both the immediate click handler and the old setTimeout(0) workaround see — in Chrome 150 they are identical.

   Interactive Code editor Selection API

why it shipped

Author intuition has always been: by the time my click handler fires, the selection should reflect what the user just did. But Chrome was dispatching click before applying the mouseup default action, so handlers saw stale selection state — typically the previous selection, not the new one the user just dragged out. The fix reorders the default action to run between mouseup and click, matching what developers (and other browsers) already assumed.

references

• ChromeStatus entry