Revert #5010 changes: no confirmed underlying issue

Ports/iOSPort/nativeSources/CN1TapGestureRecognizer.m

@@ -99,21 +99,6 @@ -(BOOL)ignoreEvent:(UITouch*)touch {
 
     BOOL ignore = (touch == nil || pressedView == nil || !viewInWindow || ![pressedView isDescendantOfView:v]);
 
-    // Touches that land on the active native text editor (the CN1UITextField /
-    // CN1UITextView created by editStringAtImpl) must be left to UIKit. They
-    // drive cursor positioning, selection handles, the magnifier loupe, and on
-    // iOS 26.x the RTI / emoji-search input session. If we dispatch them into
-    // CN1's pointer pipeline, touchesEnded fires foldKeyboard -- whose
-    // 22pt-tall hit-test rect rejects most taps on a single-line TextField --
-    // which calls stringEdit(YES,...), tears down editingComponent, and lets
-    // the same touch's pointerReleasedC re-enter Java's TextArea.pointerReleased,
-    // which recreates the field. The visible symptom is the keyboard bouncing
-    // and the selection / cursor resetting on every interaction; see #5010.
-    if (!ignore && editingComponent != nil && pressedView != nil
-            && [pressedView isDescendantOfView:editingComponent]) {
-        ignore = YES;
-    }
-
     return ignore;
 }
 

Ports/iOSPort/nativeSources/CodenameOne_GLViewController.m

@@ -538,10 +538,7 @@ void cn1_setStyleDoneButton(CN1_THREAD_STATE_MULTI_ARG UIBarButtonItem* btn) {
     if(isIOS8() && displayHeight < displayWidth) {
         showToolbar = NO;
     }
-    // #5010 diagnostic: bounded one-line marker so device logs can correlate
-    // "edit session started" against the press / text-input traces.
-    CN1Log(@"[#5010] editStringAtImpl ENTRY isSingleLine=%d maxSize=%d constraint=%d initialLen=%d existingEditing=%p",
-           isSingleLine, maxSize, constraint, len, editingComponent);
+    //CN1Log(@"Java_com_codename1_impl_ios_IOSImplementation_editStringAtImpl");
     currentlyEditingMaxLength = maxSize;
     // Honored by the UITextView shouldChangeTextInRange: delegate (EAGLView/METALView) to
     // intercept Return on multi-line text areas when the iosReturnExitsEditing client
@@ -2704,27 +2701,7 @@ - (void)remoteControlReceivedWithEvent:(UIEvent *)receivedEvent {
 // Mac Catalyst host keyboard, hardware keyboard in the iOS simulator via
 // Cmd-Shift-K). UIKey arrived in iOS 13.4 -- on older versions the
 // responder chain falls back to the existing UITextField editing path.
-//
-// While a native text editor is up (editingComponent != nil) we must not
-// touch the press at all -- not even forward to [super pressesBegan:].
-// The CN1UITextField is the first responder and handles every printable
-// key via its own pressesBegan: / insertText: pipeline before the event
-// walks up to us. Forwarding to [super pressesBegan:] re-enters
-// UIViewController's default chain walk, which on iPhone / 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 -- see
-// #5010). Returning early keeps the override fully transparent while
-// editing and preserves HW-keyboard support (#3498) for non-editing
-// state. The keyboard NSLog calls are intentionally left in for #5010
-// diagnostics; volume is bounded because pressesBegan only fires on
-// physical key events.
 - (void)pressesBegan:(NSSet<UIPress *> *)presses withEvent:(UIPressesEvent *)event {
-    if (editingComponent != nil) {
-        CN1Log(@"[#5010] pressesBegan SKIPPED while editing (count=%lu editingComponent=%p)",
-               (unsigned long)presses.count, editingComponent);
-        return;
-    }
-    CN1Log(@"[#5010] pressesBegan handling (count=%lu)", (unsigned long)presses.count);
     if (@available(iOS 13.4, *)) {
         BOOL handled = NO;
         NSMutableSet *passthrough = nil;
@@ -2755,12 +2732,6 @@ - (void)pressesBegan:(NSSet<UIPress *> *)presses withEvent:(UIPressesEvent *)eve
 }
 
 - (void)pressesEnded:(NSSet<UIPress *> *)presses withEvent:(UIPressesEvent *)event {
-    if (editingComponent != nil) {
-        CN1Log(@"[#5010] pressesEnded SKIPPED while editing (count=%lu editingComponent=%p)",
-               (unsigned long)presses.count, editingComponent);
-        return;
-    }
-    CN1Log(@"[#5010] pressesEnded handling (count=%lu)", (unsigned long)presses.count);
     if (@available(iOS 13.4, *)) {
         BOOL handled = NO;
         NSMutableSet *passthrough = nil;
@@ -2791,12 +2762,6 @@ - (void)pressesEnded:(NSSet<UIPress *> *)presses withEvent:(UIPressesEvent *)eve
 }
 
 - (void)pressesCancelled:(NSSet<UIPress *> *)presses withEvent:(UIPressesEvent *)event {
-    if (editingComponent != nil) {
-        CN1Log(@"[#5010] pressesCancelled SKIPPED while editing (count=%lu editingComponent=%p)",
-               (unsigned long)presses.count, editingComponent);
-        return;
-    }
-    CN1Log(@"[#5010] pressesCancelled handling (count=%lu)", (unsigned long)presses.count);
     if (@available(iOS 13.4, *)) {
         for (UIPress *press in presses) {
             UIKey *key = press.key;

scripts/input-validation-app/README.adoc

@@ -1,8 +1,8 @@
 = CN1 Input Validation App
 
 A minimal Codename One app whose only purpose is to assert that physical
-input events (tap, drag, long-press, keyboard) reach Component listeners
-end-to-end on iOS. Driven by XCUITest on the iOS simulator.
+input events (tap, drag, long-press) reach Component listeners end-to-end
+on iOS. Driven by XCUITest on the iOS simulator.
 
 == Why a separate pipeline?
 
@@ -44,15 +44,6 @@ the expected time.
 | `addLongPressListener` fires for a press-and-hold. Routes through the
   same touch chain as tap, so a recognizer that cancels touches mid-press
   causes this step to time out.
-
-| `keytype`
-| Typed characters reach a CN1 `TextField.DataChangedListener`. The
-  driver taps the field to bring up native iOS editing, then synthesises
-  keystrokes via `XCUIApplication.typeText`. typeText drives the
-  simulator's HW-keyboard pathway, which on iOS 13.4+ surfaces as
-  `UIPress` events through `GLViewController` -- the path #5010 broke
-  by treating every printable key as "handled" and never forwarding it
-  to UIKit's text-input pipeline.
 |===
 
 == Log markers

scripts/input-validation-app/common/src/main/java/com/codenameone/inputvalidation/gestures/GestureSuite.java

@@ -39,17 +39,6 @@ public GestureSuite() {
                 new TapStep(),
                 new DragStep(),
                 new LongPressStep()
-                // KeyTypeStep is disabled pending #5010 resolution. The
-                // step exercises the HW-keyboard UIPress chain (typeText in
-                // XCUITest), which depends on [super pressesBegan:] being
-                // forwarded from CodenameOne_GLViewController while a field
-                // is being edited. The iOS-26.4.2 freeze investigation
-                // points to that same forwarding as the trigger, so the
-                // override now returns early without forwarding -- which
-                // breaks this step on the simulator. Re-enable once the
-                // freeze root cause and a fix that preserves both paths
-                // are landed.
-                //, new KeyTypeStep()
         };
         this.form = new Form("Input Validation", new BorderLayout());
         this.statusLabel = new Label("Initializing");

scripts/input-validation-app/drivers/run-ios.sh

@@ -187,13 +187,6 @@ REQUIRED_EVENTS=(
   "CN1IV:EVENT:drag"
   "CN1IV:READY:longpress"
   "CN1IV:EVENT:longpress"
-  # keytype is disabled pending #5010 resolution -- see GestureSuite.java
-  # and ios-tests/Sources/InputValidationUITests.swift. Re-enable both
-  # CN1IV:READY:keytype and CN1IV:EVENT:keytype together when a fix
-  # that preserves both the HW-keyboard UIPress chain and the iOS-26.4.2
-  # virtual-keyboard freeze fix has landed.
-  # "CN1IV:READY:keytype"
-  # "CN1IV:EVENT:keytype"
   "CN1IV:SUITE:FINISHED"
 )
 FAILED=0

scripts/input-validation-app/ios-tests/Sources/InputValidationUITests.swift

@@ -52,15 +52,6 @@ final class InputValidationUITests: XCTestCase {
 
         try driveLongPress(app: app)
         Thread.sleep(forTimeInterval: stepDelaySeconds)
-
-        // KeyTypeStep is disabled pending #5010 resolution. See the
-        // matching note in GestureSuite.java and the removed assertion in
-        // drivers/run-ios.sh. The driveKeyType helper is intentionally
-        // kept below so the step is one-line re-enable once a fix that
-        // preserves both the HW-keyboard UIPress chain and the iOS-26.4.2
-        // virtual-keyboard freeze fix has landed.
-        // try driveKeyType(app: app)
-        // Thread.sleep(forTimeInterval: stepDelaySeconds)
     }
 
     private func driveTap(app: XCUIApplication) throws {
@@ -80,21 +71,4 @@ final class InputValidationUITests: XCTestCase {
         let center = app.coordinate(withNormalizedOffset: CGVector(dx: 0.5, dy: 0.5))
         center.press(forDuration: 1.5)
     }
-
-    private func driveKeyType(app: XCUIApplication) throws {
-        // KeyTypeStep places its TextField in BorderLayout.CENTER with
-        // generous padding/margin, matching the layout TapStep and
-        // LongPressStep use so a single screen-center tap focuses it on
-        // every iPhone size class on the CI runner. Wait briefly after
-        // the tap for CN1's editStringAtImpl to install the native
-        // CN1UITextField and animate the keyboard in -- typeText raises
-        // "Neither element nor any descendant has keyboard focus" if no
-        // first responder accepts input yet -- then type. typeText
-        // synthesises HW-keyboard UIPress events that walk through
-        // GLViewController, exactly the path #5010 broke.
-        let center = app.coordinate(withNormalizedOffset: CGVector(dx: 0.5, dy: 0.5))
-        center.tap()
-        Thread.sleep(forTimeInterval: 2.0)
-        app.typeText("cn1")
-    }
 }