Skip to content

iOS: keep the port's keyboard handlers out of the SMS composer - #6220

Merged
shai-almog merged 1 commit into
masterfrom
ios-sms-composer-keyboard
Nov 12, 2026
Merged

shai-almog merged 1 commit into
masterfrom
ios-sms-composer-keyboard

Conversation

@shai-almog

Copy link
Copy Markdown
Collaborator

Issue #6211 reports the native SMS composer intermittently opening with its message field and send button behind the keyboard, with no text field of the application being edited.

The composer is Apple's UI, but iOS keyboard notifications are process wide, so its keyboard reached the port's keyboardWillShow/keyboardWillHide handlers as if one of our own text fields had raised it. They recorded a keyboard height, called into Java (which fires the application's virtual keyboard listeners and can pad and revalidate the current form) and repainted underneath the sheet.

What changes

  • sendSMS suspends the port's keyboard handling while the composer is presented, and the composer's delegate resumes it before dismissing.
  • While suspended, a "will show" is ignored. The "will hide" that pairs with it is dropped too, so listeners never get a "hidden" for a keyboard they were not told about.
  • A hide is still handled when one of our own keyboards is on record: if an editor had the keyboard up as the composer opened, that hide is what puts the view and the form back.
  • The flag clears itself when nothing is presented, and is not set when something else is already presented, so it cannot outlive the sheet and break text editing.

Testing

Not reproduced and not verified on a device: the iOS simulator reports canSendText as NO and will not present the composer, so this needs a physical iPhone. Both files were syntax-checked against a generated iOS project. Reading the handlers found no code that moves a view when nothing is being edited, so this is a workaround that also tells us whether the handlers are involved at all: if the problem persists with this change, they are ruled out.

🤖 Generated with Claude Code

The keyboard notifications are process wide, so the keyboard of the native
SMS composer reached keyboardWillShow/keyboardWillHide as if one of our own
text fields had raised it: they recorded a keyboard height, called into
Java and repainted underneath the sheet. Issue #6211 reports the composer
intermittently opening with its entry field behind the keyboard.

sendSMS now suspends that handling while the composer is presented. A show
is ignored, and so is the hide that pairs with it, unless one of our own
keyboards is still on record -- that hide is what restores the view. The
flag clears itself when nothing is presented, so it cannot outlive the
sheet and break text editing.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
@shai-almog
shai-almog merged commit 778eb0e into master Nov 12, 2026
16 of 17 checks passed
@shai-almog
shai-almog deleted the ios-sms-composer-keyboard branch November 12, 2026 12:18
@github-actions

Copy link
Copy Markdown
Contributor

✅ Continuous Quality Report

Test & Coverage

Static Analysis

  • SpotBugs [Report archive]
    • ✅ ByteCodeTranslator: 0 findings (no issues)
    • ✅ android: 0 findings (no issues)
    • ✅ android-compat: 0 findings (no issues)
    • ✅ android-res-compiler: 0 findings (no issues)
    • ✅ backend: 0 findings (no issues)
    • ✅ backend-test: 0 findings (no issues)
    • ✅ build-engine: 0 findings (no issues)
    • ✅ build-hint-catalog: 0 findings (no issues)
    • ✅ build-hint-tools: 0 findings (no issues)
    • ✅ codenameone-gradle-plugin: 0 findings (no issues)
    • ✅ codenameone-maven-plugin: 0 findings (no issues)
    • ✅ compose-compat: 0 findings (no issues)
    • ✅ core-unittests: 0 findings (no issues)
    • ✅ desktop-compat-runtime: 0 findings (no issues)
    • ✅ fxml-compiler: 0 findings (no issues)
    • ✅ ios: 0 findings (no issues)
    • ✅ javac: 0 findings (no issues)
    • ✅ javafx-compat: 0 findings (no issues)
    • ✅ project-model: 0 findings (no issues)
    • ✅ python-runtime: 0 findings (no issues)
    • ✅ python-transpiler: 0 findings (no issues)
    • ✅ swing-compat: 0 findings (no issues)
  • ✅ PMD: 0 findings (no issues) [Report archive]
  • ✅ Checkstyle: 0 findings (no issues) [Report archive]

Generated automatically by the PR CI workflow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant