Repository navigation
Google Docs: do not show suggestions when a click only moves the caret - #479
Merged
Merged
Conversation
… caret In Google Docs, a click into existing text opened the suggestion menu. An arrow key did the same. The user did not type. Root cause: the adapter reads the Docs model every 200 ms. It asks for suggestions when the new snapshot is not the same as the last one. A click (pointerdown) and each key call dismiss(), and dismiss() sets the stored snapshot to null. The next poll then had no snapshot to compare, so it read the moved caret as a change and asked for suggestions. Fix: a new "edited" flag. An edit sets it: a keystroke, an input, a paste (queueEdit), the end of an IME composition, and our own write (so the next-word menu still shows after an accepted word). dismiss() clears it. A read uses it one time. A read without an edit or an explicit request (force) asks for no suggestions. Tests: - unit (GoogleDocsAdapter.test.ts): a click and a poll ask for no suggestions; an edit does. It fails without the fix. - integration (google-docs.e2e.test.ts): pointerdown plus a caret move, and an arrow key plus a caret move, request no suggestions, and the menu stays closed. Without the fix, the menu opens. - e2e (full.e2e.test.ts): for 24 editor setups (textarea, input, contenteditable, React-controlled fields, CKEditor 4/5, Quill, Lexical, ProseMirror, Slate, TinyMCE, Gutenberg, Draft.js, Trix, Froala, Summernote, Tiptap, RoosterJS and the Notion-like page), in menu and inline mode: a click into the text, arrow keys, and a click back into the field show no suggestion. All 48 cases pass in Chrome. These editors did not have the bug. When a click asks for suggestions on purpose, the test fails. - The coverage matrix has a new behavior, caret_move_shows_no_suggestion. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
In Google Docs, a click into existing text opened the suggestion menu, and an arrow key did the same, without any typing.
Root cause
The Docs adapter reads the model every 200 ms. It asks for suggestions when the new snapshot differs from the last one. A click (
pointerdown) and each key calldismiss(), anddismiss()sets the stored snapshot tonull. The next poll then has no snapshot to compare against, so it reads the moved caret as a change and asks for suggestions.Fix
GoogleDocsAdapterhas a neweditedflag:queueEdit), the end of an IME composition, and our own write. Thus the next-word menu still shows after an accepted word.dismiss()clears it.force, for example Ctrl+Space) asks for no suggestions.Other editors
I checked whether other editors have the same bug. A new e2e test runs the same steps in 24 editor setups, each in menu mode and inline mode:
For each one, it types text, then clicks into the middle of a word, presses arrow keys, and clicks back into the field from outside. All 48 cases pass in Chrome, so the bug is only in Google Docs. To prove the test can catch the bug, I added a click-triggered prediction on purpose. Then the test failed for textarea, contenteditable, Lexical and Notion.
Tests
tests/GoogleDocsAdapter.test.tsfails without the fix.tests/e2e/google-docs.e2e.test.tshas a new test for a click and an arrow key that only move the caret. Without the fix, the menu opens. With the fix, all 91 Docs e2e tests pass.bun run check,bun run test(0 failures) andbun run check:e2e:coveragepass. The coverage matrix has a new behavior,caret_move_shows_no_suggestion.Reviewer notes
🤖 Generated with Claude Code