Repository navigation
Description
What happened
On a Pixel 10 XL running Android 17 and T3 mobile app 2.2.0, accepting a Gboard suggestion or spelling correction in an agent question response field puts the field into a broken typing state. The cursor moves before the last typed character, causing subsequent characters to land in the wrong place.
The same keyboard suggestions and spelling corrections work normally in the main composer on the same device. The user explicitly identified the question response field as the affected surface.
Expected: Accepting a keyboard suggestion or spelling correction should preserve a usable insertion point, and subsequent typing should proceed normally in the question response field.
Actual: The question response field becomes impractical to type in after a suggestion/correction. The user pasted responses to get around the problem before finding that moving the cursor to the end of the line recovers it.
Diagnosis
In the inspected local source, the two surfaces use different input implementations. PendingUserInputCard renders QuestionAttachments, whose AppTextInput wraps a controlled React Native TextInput. The main composer uses T3's custom native ComposerEditor. The question response path stores custom text in a local atom; no per-keystroke network request is evident in that path.
The same-device comparison makes the question-response implementation and its handling of Gboard replacement/composition events the primary investigation target. It does not establish a specific React Native, Gboard, or T3 root cause.
The user initially suspected incoming assistant responses might trigger the problem. That remains unconfirmed. Ordinary idle typing worked, and accepting a keyboard suggestion is the more specific reported trigger. Whether concurrent streaming worsens the problem has not been isolated.
Steps to reproduce
- Open an agent question's custom-response field in T3 mobile on Android.
- Type text. Ordinary typing initially worked while the agent was idle.
- Tap a Gboard suggestion or spelling correction.
- Continue typing. The cursor repeatedly jumps backward before the last typed character.
- Move the cursor to the end of the line. The user reports this restores normal typing.
- Compare the same keyboard suggestion and correction actions in the main composer: the user reports they work normally there.
Version
T3 mobile app 2.2.0; connected host server 0.1.6
Environment
Device: Pixel 10 XL.
OS: Android 17.
Affected app: T3 mobile 2.2.0.
Keyboard: stock Gboard with the latest available updates per user; exact Gboard build number not supplied.
App distribution channel: not yet supplied.
Connected host: macOS arm64, T3 server 0.1.6, desktop Beta installation.
Evidence
User confirmed the question response field was affected, accepting a suggestion caused the broken state, moving to the line end recovered it, and normal suggestions/spelling fixes worked in the main composer.
Source leads: apps/mobile/src/features/threads/QuestionAttachments.tsx; components/ui/AppText.tsx; state/use-selected-thread-requests.ts; native/T3ComposerEditor.native.tsx.
Source inspected: existing local checkout 7d9725a, not established as the exact shipped mobile 2.2.0 build. This is a user-observed reproduction with source leads, not an instrumented physical-device or emulator reproduction.
Related issues
#18732 describes main-composer caret movement after scrolling. The surface and trigger differ, so it is not a confirmed duplicate.
#11337 fixed a web question-answer editor path; it does not establish an Android fix.
Fix applied or workaround
Move the cursor to the end of the line after the suggestion/correction, or paste a response composed elsewhere. Suggestions work in the main composer, but it is not a replacement for submitting a pending question answer.
Filed by
Codex, gpt-6.1-sol; T3 triage playbook followed in existing session.
Activity
mayesidev commentedon Nov 2, 2026
Superseded by #29349. The identical report was recreated using the repository's Triage report template, which correctly applies via-triage. Please track the bug in #29349.