Repository navigation
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. Important Review skippedReview was skipped as selected files did not have any reviewable changes. ⚙️ Run configurationConfiguration used: Repository: pingdotgg/t3code/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: pingdotgg/t3code/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughThe editor’s ChangesEditor focus
Priority: ➖ Normal Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to The composer now synchronizes its selection through ProseMirror when focused, without changing viewport behavior. No concrete user impact remains, so this change is ready to merge. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
…oser Dictating into a blurred composer scrambled the text: type-to-focus redirected the first keystroke, but the editor's DOM caret stayed at offset 0 until ProseMirror resynced it 20ms later, so fast dictation keys landed ahead of it. Carry pingdotgg/t3code#13708, which focuses through ProseMirror so the caret is placed synchronously.
…ks in
When the composer is blurred, the first keystroke is redirected into the draft and the editor
is focused a frame later. That focus used a bare DOM focus, which leaves the native caret at
the start of the editor until ProseMirror resyncs it about 20ms later. Voice dictation tools
such as whisrs type faster than that, so the next keys landed ahead of the redirected text
("Testing 1, 2, 3." became ", 3.Testing 1, 2").
Focus through ProseMirror's view.focus(), which writes the state selection to the DOM as it
focuses, so the caret is at the end before the next key arrives.
b2d602e to
f6b231b
Compare
|
Note This comment is posted by Julius' dot The burst-test results describe the caret race, but no recording shows the type-to-focus handoff before and after. This timing change needs one under the verification requirement. I'm closing this pending a short clip showing the blurred composer, rapid input and resulting text. Attach it and request reconsideration. |
What Changed
focusAtin the Tiptap composer now focuses through ProseMirror'sview.focus()instead of a bareview.dom.focus().Why
When the composer is blurred, type-to-focus redirects the first keystroke into the draft and focuses the editor a frame later. A bare DOM focus leaves the native caret at offset 0. ProseMirror's state selection is already at the end (the controlled update set it while the editor was blurred), so the following
setTextSelectionchanges nothing and nothing gets synced to the DOM. ProseMirror only resyncs the DOM caret in a 20ms timeout after focus. Voice dictation tools (here, whisrs over uinput at ~4ms per character) type faster than that, so keys landed ahead of the redirected text: dictating "Testing 1, 2, 3." produced ", 3.Testing 1, 2".view.focus()does the same no-scroll focus and writes the state selection to the DOM synchronously, so the caret is at the end before the next key arrives.Verified in a dev build by blurring the composer and firing a 1–4ms keydown burst (redirected keys first, then native insertion once the editor has focus):
esting 1, 2, 3.T,2, 3.Testing 1,, ...). Instrumentation showed ProseMirror's selection at the end while the DOM caret was at 0.UI Changes
None visible. Only the caret placement timing changes.
Checklist
Done with Claude Opus 5.5 in Claude Code (via T3 Code).
Summary by CodeRabbit