fix(web): scroll to the caret after an edit the composer performs itself

Pasting a long block left the view where it was while the caret sat at the
end of what was pasted. Paste, ctrl/meta-Enter newline and cut all suppress
the native edit — the machine owns the draft and the undo log — and restore
the caret with `setSelectionRange`, which reveals nothing: measured in
chromium and WebKit, before this branch as well as on it. Firefox happened to
reveal it, in the old geometry only.

The three restores now share one helper that measures the caret against the
hidden mirror — same draft, same metrics, same wrap width, so a Range
collapsed at the caret's index reports where the caret is without a caret API
— and scrolls the scrollport the minimum that brings the line inside, which
is what the browser does for typing. One scrollport is what makes this
possible at all: the reveal is finally a single offset to move.

Also from review: the composer's own focus() on unlock and session switch
passes preventScroll, so a session switch cannot move the transcript through
the taller textarea's reveal chain.

This commit is contained in:

creatixchu

2026-07-31 16:07:55 +08:00

parent 49f8cdd401

commit e465806120

7 changed files with 163 additions and 17 deletions

									
										apps/web/tests/snapshots/composer-draft-scroll/geometry.expected.md
									
		+6
		
												View File
												
				@@ -23,3 +23,9 @@

				- caret sits on its own glyphs: true

				- the draft's own last line is on screen: true

				## Right after pasting a long block at the end

				- the composer scrolled to the caret it left: true

				- caret and glyphs stay level when the offset changes: true

				- the pasted block's last line is on screen: true