Repository navigation
Stop the keyboard and Backtalk waiting on each other in Backtalk's fields - #225
Merged
aryanchoudharypro merged 3 commits intoOct 20, 2026
Merged
Conversation
…elds Typing quickly in one of Backtalk's own text fields, such as a settings dialog or screen search, could stall for seconds and lose keys. A keyboard asks the field about its text as it types, and Backtalk's fields answered on its main thread. That thread also asks the keyboard about its keys, so each could wait for the other until the keyboard gave up two seconds later. Backtalk's text fields now answer the keyboard on a thread of their own. Each call still runs on the main thread, in order, but the keyboard waits for it at most 150 ms. A change to the text that takes longer still happens; a question about the text that takes longer goes unanswered, which keyboards handle as they do a field that can't say. Text fields in other apps answer on those apps' own main threads, so this can't happen there. - KeyboardCalls answers an InputConnection on its own thread. - KeyboardSafeEditText uses it, in every Backtalk layout and dialog, and in place of AndroidX Preference's EditTextPreference dialog layout. - Unit tests for answering while the main thread is free and busy, and for changes made while it is busy.
Typing quickly in one of Backtalk's own fields could still stall for seconds and scramble the text. Each call from the keyboard waited up to 150 ms for the main thread, changes included, so while the main thread was waiting for the keyboard, a question queued behind several changes waited for all of them, and the keyboard with it. The keyboard doesn't wait for changes to the text, so they are now made on the main thread without waiting. After a question goes unanswered because the main thread is busy, later questions are unanswered at once until the main thread has run it. - Unit tests for changes not waiting, questions while the main thread is busy and after it is free, and a question seeing an earlier change.
mad-gamer26
added a commit
to mad-gamer26/BacktalkRemote
that referenced
this pull request
Oct 20, 2026
Brings in the keyboard-safe text fields (trypsynth#225), which also cover the remote access key and relay server dialogs through the replaced EditTextPreference layout, settings that open before Backtalk has connected (trypsynth#226), and the fresh reading order search (trypsynth#221). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SKArzG82mfYh483GfqQKFo
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
2 participants
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.
Typing quickly in one of Backtalk's own text fields, such as a settings dialog or screen search, could stall for seconds and lose or scramble keys.
As a keyboard types, it asks the field about its text and waits for the answer. Backtalk's fields are in Backtalk's own process, so they answered on its main thread. That thread also makes synchronous accessibility requests to the keyboard's window about its keys. Each side waited for the other until the keyboard gave up, about two seconds later.
Backtalk's text fields now answer the keyboard on a thread of their own (
KeyboardCalls, used byKeyboardSafeEditText). Each call still runs on the main thread, in order.KeyboardSafeEditTextis used in every Backtalk layout and dialog that has a text field. It also replaces AndroidX Preference's EditTextPreference dialog layout.Text fields in other apps answer on those apps' own main threads, so this can't happen there.
Limitations: while the main thread is busy, questions about the text go unanswered. Keyboards handle that as they do a field that can't answer. A keyboard can then misjudge the cursor position for keys typed during that time.
Tested: