Fix #5010: don't swallow UIPress events while editing a native text component#5013
Merged
Merged
Conversation
…omponent The hardware-keyboard handler in CodenameOne_GLViewController consumed every UIPress whose UIKey mapped to a non-zero CN1 keycode -- and for printable characters cn1MapUIKeyToKeyCode returns the unicode codepoint, which is always non-zero. With handled=YES the press was never forwarded to [super pressesBegan:], so UIKit's text-input pipeline never converted it into insertText: on the focused CN1UITextField / CN1UITextView. That broke hardware-keyboard typing outright on iOS 13.4+ (BT keyboards, Magic Keyboard, simulator HW keyboard) the moment a text field was being edited. On iOS 26.x devices, where some on-screen keyboard interactions also reach the responder chain as UIPress events, the same path also swallowed virtual-keyboard typing -- the reporter's "cursor blinks but typing does nothing" symptom in #5010. Bypass the intercept entirely while editingComponent != nil. CN1 KeyEvent listeners legitimately stop firing during text editing, which matches the intuition that arrow keys etc. should move the caret rather than trigger app-level navigation while a field is focused. Verified on iPhone 17 Pro / iOS 26.3 simulator: with a single TextField focused, typing on the Mac host keyboard now lands characters in the field. Prior to the fix the same keystrokes were silently dropped. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Extends the input-validation pipeline with a fourth gesture step that proves keyboard input lands in a CN1 TextField. The driver taps the field to bring up native iOS editing, then synthesises keystrokes via XCUIApplication.typeText -- which routes through the simulator's HW-keyboard pathway, raising UIPress events that walk through CodenameOne_GLViewController on iOS 13.4+. Without the companion fix in CodenameOne_GLViewController.m, every printable keystroke is consumed by pressesBegan: before UIKit converts it into insertText: on the focused CN1UITextField, the DataChangedListener never fires, and this step times out. With the fix, "cn1" propagates end-to-end through CN1UITextField -> UITextFieldTextDidChangeNotification -> EAGLView.textFieldDidChange -> stringEdit -> TextField.setText -> DataChangedListener and the step asserts CN1IV:EVENT:keytype. The pipeline already covers #5003's tap/drag/longpress regressions along the same touch chain; #5010 sits one layer deeper on the responder chain (UIPress instead of UITouch) and needs its own probe. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
Collaborator
Author
|
Compared 110 screenshots: 110 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 110 screenshots: 110 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
The first CI run of the new keytype step timed out: XCUITest threw
"Neither element nor any descendant has keyboard focus" from
`app.typeText("cn1")` because the (0.5, 0.18) tap landed in empty
space below the TextField. The field had been added to
BorderLayout.NORTH of the target area, which on the CI iPhone SE
runner put it well above the y=0.18 band the driver tapped, so the
field never entered editing mode and no first responder was available
for typeText to write into.
Switch the layout to match TapStep / LongPressStep: TextField in
BorderLayout.CENTER with the same padding+margin sizing, tapped at
the centered (0.5, 0.5) coordinate the other steps already use
successfully. Also bumps the post-tap sleep to 2.0s for the slower
boot of the CI simulator's keyboard animation.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
6 tasks
shai-almog
added a commit
that referenced
this pull request
May 24, 2026
…editing The #5013 hotfix changed pressesBegan/Ended/Cancelled to call [super pressesBegan:] when a native text editor was up, instead of swallowing the press via the cn1MapUIKeyToKeyCode path. The intent was to let UIKit's text-input pipeline deliver the press to the focused CN1UITextField. That worked on the iOS 26.3 simulator (where the verification happened) but did not fix the freeze the reporter saw on iPhone 14 Plus / iOS 26.4.2. The CN1UITextField is the first responder. iOS delivers UIPress events to the first responder first; the field's own pressesBegan: / insertText: handles printable keys before the event walks up the responder chain to our view controller. Forwarding to [super pressesBegan:] from our override re-enters UIViewController's default chain walk, which on iOS 26.4.2 hangs the next inbound key delivery -- the user sees a focused field where typing does nothing and the rest of the app freezes, requiring a restart. Change each press handler to return immediately when editingComponent is set, with no [super pressesBegan:] forwarding. The override is now fully transparent while editing: the field's own handling stands and the chain stops here. HW-keyboard support (#3498 / #4982) for non- editing state is preserved by the unchanged fallthrough. Also adds bounded CN1Log markers at each press handler entry and at editStringAtImpl entry so any future device log can correlate edit session start, press routing, and the editing-vs-not branch taken. Volume is bounded -- pressesBegan only fires on physical key events, and editStringAtImpl only fires once per edit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4 tasks
shai-almog
added a commit
that referenced
this pull request
May 24, 2026
KeyTypeStep was added in #5013 to assert that HW-keyboard typeText (XCUITest's HW-keyboard pathway, surfacing as UIPress events on iOS 13.4+) reaches the focused CN1UITextField's insertText: via the responder chain walk through CodenameOne_GLViewController. That walk depends on the controller's pressesBegan: forwarding to [super pressesBegan:] while a field is being edited. The companion commit on this branch makes pressesBegan / pressesEnded / pressesCancelled return early without forwarding super while editingComponent != nil, because that same forwarding is the suspected trigger for the iOS-26.4.2 freeze the reporter still sees after #5026. The two fixes are mutually exclusive on the simulator: enable HW typing via super forwarding (KeyTypeStep passes, virtual-keyboard freeze persists), or block super forwarding (freeze hopefully fixed, KeyTypeStep times out on the typeText path). Disable KeyTypeStep here while we ship the freeze probe to the reporter. All three layers are commented (not deleted) so re-enabling is a one-line revert once the right fix that preserves both paths is known: - GestureSuite.java: KeyTypeStep dropped from the steps[] array - InputValidationUITests.swift: driveKeyType call commented, helper kept - drivers/run-ios.sh: CN1IV:READY:keytype + CN1IV:EVENT:keytype dropped from REQUIRED_EVENTS Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
shai-almog
added a commit
that referenced
this pull request
May 24, 2026
…editing (#5027) * Fix #5010: make pressesBegan/Ended/Cancelled fully transparent while editing The #5013 hotfix changed pressesBegan/Ended/Cancelled to call [super pressesBegan:] when a native text editor was up, instead of swallowing the press via the cn1MapUIKeyToKeyCode path. The intent was to let UIKit's text-input pipeline deliver the press to the focused CN1UITextField. That worked on the iOS 26.3 simulator (where the verification happened) but did not fix the freeze the reporter saw on iPhone 14 Plus / iOS 26.4.2. The CN1UITextField is the first responder. iOS delivers UIPress events to the first responder first; the field's own pressesBegan: / insertText: handles printable keys before the event walks up the responder chain to our view controller. Forwarding to [super pressesBegan:] from our override re-enters UIViewController's default chain walk, which on iOS 26.4.2 hangs the next inbound key delivery -- the user sees a focused field where typing does nothing and the rest of the app freezes, requiring a restart. Change each press handler to return immediately when editingComponent is set, with no [super pressesBegan:] forwarding. The override is now fully transparent while editing: the field's own handling stands and the chain stops here. HW-keyboard support (#3498 / #4982) for non- editing state is preserved by the unchanged fallthrough. Also adds bounded CN1Log markers at each press handler entry and at editStringAtImpl entry so any future device log can correlate edit session start, press routing, and the editing-vs-not branch taken. Volume is bounded -- pressesBegan only fires on physical key events, and editStringAtImpl only fires once per edit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Input validation: disable KeyTypeStep pending #5010 resolution KeyTypeStep was added in #5013 to assert that HW-keyboard typeText (XCUITest's HW-keyboard pathway, surfacing as UIPress events on iOS 13.4+) reaches the focused CN1UITextField's insertText: via the responder chain walk through CodenameOne_GLViewController. That walk depends on the controller's pressesBegan: forwarding to [super pressesBegan:] while a field is being edited. The companion commit on this branch makes pressesBegan / pressesEnded / pressesCancelled return early without forwarding super while editingComponent != nil, because that same forwarding is the suspected trigger for the iOS-26.4.2 freeze the reporter still sees after #5026. The two fixes are mutually exclusive on the simulator: enable HW typing via super forwarding (KeyTypeStep passes, virtual-keyboard freeze persists), or block super forwarding (freeze hopefully fixed, KeyTypeStep times out on the typeText path). Disable KeyTypeStep here while we ship the freeze probe to the reporter. All three layers are commented (not deleted) so re-enabling is a one-line revert once the right fix that preserves both paths is known: - GestureSuite.java: KeyTypeStep dropped from the steps[] array - InputValidationUITests.swift: driveKeyType call commented, helper kept - drivers/run-ios.sh: CN1IV:READY:keytype + CN1IV:EVENT:keytype dropped from REQUIRED_EVENTS Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 tasks
shai-almog
added a commit
that referenced
this pull request
May 26, 2026
…firmed (#5041) Removes the iOS native edits and the input-validation test scaffolding that were added to chase issue #5010. The bug reporter's symptoms could not be independently reproduced, so the workarounds are removed: - pressesBegan/Ended/Cancelled editingComponent guards in CodenameOne_GLViewController (PRs #5013, #5027) - ignoreEvent extension on CN1TapGestureRecognizer (PR #5026) - CN1Log [#5010] diagnostic markers in editStringAtImpl and the press handlers (PR #5027) - KeyTypeStep + driveKeyType XCUITest scaffolding that only existed to validate the fix path (PR #5013) CodenameOne_GLViewController.m is now byte-identical to its pre-#5010 baseline; CN1TapGestureRecognizer.m differs only in two trailing- whitespace cleanups. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2 tasks
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.
Summary
CodenameOne_GLViewController.m'spressesBegan:/pressesEnded:/pressesCancelled:treat everyUIPresswhoseUIKeymaps to a non-zero CN1 keycode as consumed.cn1MapUIKeyToKeyCodereturns the unicode codepoint for any printable character, so every printable HW-keyboard keystroke was being silently swallowed once aCN1UITextField/CN1UITextViewwas up. UIKit's text-input pipeline never got the press, so noinsertText:ever fired on the focused field. On iOS 26.x devices, where some on-screen keyboard interactions also surface asUIPressevents on the responder chain, the same path also kills virtual-keyboard typing — the reporter's "cursor blinks but typing does nothing" symptom in Unresposive App when trying to type to input field #5010.editingComponent != nil. Verified on iPhone 17 Pro / iOS 26.3 simulator: HW-keyboard typing into a focusedTextFieldnow lands characters in the field; previously the same keystrokes were dropped.keytypestep that taps a CN1TextFieldthen drivesXCUIApplication.typeText.typeTextsynthesises HW-keyboard keystrokes, so this step exercises the exactUIPresspath Unresposive App when trying to type to input field #5010 broke. Without the fix the step times out; with the fix the suite assertsCN1IV:EVENT:keytypeend-to-end.Test plan
TextField, type via the simulator HW keyboard — characters now appear in the field (iPhone 17 Pro / iOS 26.3 simulator).mvn -pl ios -am clean install).xcodebuild testfor the input-validation XCUITest target — pending CI to verify on a clean runner.