Conversation
The ⏎ key committed a literal "\n". Most editors never see that as a submit: they declare an editor action in imeOptions and act on that instead, so Enter looked dead — a WhatsApp message could be dictated but not sent, and a browser search could be typed but not run. Fire the declared action when the field has one, fall back to a real ENTER key event when it does not, and keep committing a newline only for genuinely multi-line editors. On Wear the field is often not the app's own: Galaxy Watch routes WhatsApp and Keep Notes through Samsung's RemoteInput activity, which declares IME_ACTION_DONE and hands the text back to the app when that action fires. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EBBqERL2Akg9cYDXRaaK7D
Hiding the keyboard the moment a dictation lands is right when the text is the whole job, as in a note. Over a field that still has to be submitted it does two things wrong: it takes away the ⏎ the user now needs, and its teardown races the commit that just happened — Samsung's browser resolves that race by dropping the transcript, so dictated text never appeared there at all. Keep the keyboard up when the field declares a submit action, and hide once that action has actually fired: the app is showing its result by then, and the input view is opaque enough to cover it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EBBqERL2Akg9cYDXRaaK7D
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
1 participant
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.
Fixes #294.
Hi! I really enjoy your apps. I paid for Dictate Wear and it was such a bummer when it
didn't work on my watch, I really was looking forward to have something like this. I know my way around adb tooling and had a feeling the fix might be simple,
so I vibed my way through it, and this is what I ended up with.
What was wrong
Two problems I described earlier turned out to be the same story.
Enter (from the numpad) didn't submit.
performEntercommitted a literal"\n". Most fields never treat that as asubmit — they declare an editor action in
imeOptionsand act on that instead. So in WhatsApp thetranscript landed in the box and just sat there, and in the Browser the search never ran.
Something that surprised me, and that may not be obvious without a Galaxy Watch (and logcat) in hand: the field
Dictate binds to is usually not the app's own. On Wear OS 6 / One UI 8 Watch, WhatsApp and Keep Notes
both go through Samsung's RemoteInput text-entry activity, so the IME sees
and the app's own window only returns (with
inputType=0x0, not an editor) once that DONE actionfires. That's why Keep Notes seemed to work while WhatsApp didn't. Samsung Browser is the exception —
a directly bound field declaring
IME_ACTION_SEARCH.Dictated text disappeared in the Browser. After a transcription the service commits the text and
immediately calls
requestHideSelf(0). Over the browser's search field that teardown races the commitand the text is dropped — the same field accepts keypad input fine, where no hide is involved. And even
where the text survived, hiding took away the ⏎ needed to send it.
What I changed
KEYCODE_ENTERwhen there is none, and commits a newline only for multi-line editors.IME_FLAG_NO_ENTER_ACTIONis respected.notes-style fields — and the keyboard hides once the action has actually fired, so it isn't left
sitting opaque over the result.
44 added lines in one file, no UI changes.
How I tested
Galaxy Watch8 (SM-L330), Wear OS 6.0 / One UI 8.0 Watch, tethered to Dictate on a Galaxy S26 Ultra
(Android 16).
Important to say, the way to send a transcripted is with the Enter button of the numpad, it is usable but maybe not ideal.
The part I can't check
I only have my own watch, so I'm blind to how this behaves elsewhere. The risk I'd flag: a field that
declares an action but expects a newline anyway would now submit instead of adding a line. I tried to
guard that with the multi-line and
IME_FLAG_NO_ENTER_ACTIONchecks, but a device reporting thingsdifferently could behave differently. If you'd rather shape this another way, I'm happy to re run checks in my watch.
This is my first time contributing to an open source project like this. Hope it helps.
🤖 Generated with Claude Code
https://claude.ai/code/session_01EBBqERL2Akg9cYDXRaaK7D