[Android] Keyboard does NOT close by any action after beeing opened by autofocus on inputfield widget.

[DimitarStoyanov91]

Steps to reproduce

1. Create emulator Pixel XL API 33 in Android Studio
2. Clone '[email protected]:Prime-Holding/widget_toolkit.git'
3. Open in Android Studio widget_toolkit->packages->widget_toolkit->example
4. Checkout branch 'fix-patrol-debug'
5. Check test 'edit_fields_test.dart'
6. Run command patrol test --target integration_test/tests/edit_fields_test.dart

Actual results

We have a widget with autofocus on the input field, which causes the keyboard to appear. The normal flow would be that the keyboard hides after clicking a "Save" button. Unfortunately when the test clicks "Save" the keyboard stays on the screen and hides other widgets underneath it. We tried $.native.tap() on some elements on the screen, but that did not hide the keyboard.

Update: Tried also this approach: Future nativeEnterText(var widget, String inputText) async { await $(widget).tap(): await checkWidgetVisibility(widget); await $.native.enterText(Selector(focused: true), text: inputText, keyboardBehavior: KeyboardBehavior.showAndDismiss); } This works fine for positive cases, but fails to enter the text when there are multiple invalid inputs for that field and a final step with valid input that is accepted.

Logs

There are no log errors.

Patrol version

Patrol version: 3.6.1 patrol_cli version: 2.7.0 Device: Android 13.0 Pixel XL API 33

Patrol Doctor output

Patrol doctor: Patrol CLI version: 2.7.0 Flutter command: flutter Flutter 3.16.3 • channel stable Android: • Program adb found in /opt/homebrew/bin/adb • Env var $ANDROID_HOME set to /Users/dimitar.stoyanov/Library/Android/sdk iOS / macOS: • Program xcodebuild found in /usr/bin/xcodebuild • Program ideviceinstaller found in /opt/homebrew/bin/ideviceinstaller

Flutter Doctor output

[✓] Flutter (Channel stable, 3.16.3, on macOS 14.1.2 23B92 darwin-arm64, locale en-GB) [✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0) [✓] Chrome - develop for the web [✓] Android Studio (version 2023.1) [✓] IntelliJ IDEA Community Edition (version 2022.3.1) [✓] Connected device (2 available) [✓] Network resources

[fylyppo]

Hi, the easiest solution to make this test passing is to close keyboard manually by putting await $.native.pressBack(); after line 18 in edit_fields_test.dart. Keyboard's behaviour seems unexpected so I'll try to come back to this case, maybe we can fix that in patrol. Let me know if it solves all cases you have.

[DimitarStoyanov91]

@fylyppo Thanks for the fast response! Unfortunately this doesn't seem to be a good workaround for us, since we have a lot of tests and we have a lot of places with this widget. This will require refactoring to most of our tests. We will wait for a more generic fix, before we jump into workarounds. I am available for more comments, questions, etc.

[b055man]

@DimitarStoyanov91 any chance it is related to this: https://github.com/leancodepl/patrol/pull/2111#issuecomment-2079825193 ?

[DimitarStoyanov91]

Hello @b055man, It seems the second part fits our issue "the keyboard does not close when the text field edit is done / the focus is lost - it stays on forever (can't really close it even when tapping back in the emulator)", please keep in mind @fylyppo noted this "Hi, the easiest solution to make this test passing is to close keyboard manually by putting await $.native.pressBack(); after line 18 in edit_fields_test.dart.". However, I can not confirm this part "Also, these tests worked fine with previous Patrol (2.3.2) and as mentioned they work fine if 2.0.1+1 version of the package is used."

[ahlstro]

Have the same problem. Got 3 solutions atm in my tests code.

1. Open and close notifications (native)
2. Scroll to the widget (use scrollTo)
3. Use enterText directly into the finder without tapping the textField widget

Would very much like a fix for this.

[weetabixhands]

I am also seeing this with patrol 3.15.1 and patrol_finders 2.7.2. Reverting back to 3.14.1 and 2.7.0 respectively has solved it for me.

[javiermrz]

Same is happening to me on patrol 3.15.1.

And for those saying that this can be solved by closing the text input with a native 'press back'... Not really :( Next time I try to open the keyboard by pressing in the input (even manually) it won't open. Something really weird is happening.

Clarification: These tests were working perfectly and broke after upgrading patrol and patrol_cli. They are not new tests.

[javiermrz]

@weetabixhands didn't you have compilation errors when rollbacking to 3.15.1? What flutter version do you have?

[obaidahmed25]

I have the same problem on patrol 3.15.2 and patrol_cli 3.6.0. Tried rolling back to the previous version but the issue still persists.

I've started using await $.native.pressBack(); as a workaround for now.

[lexxxel]

Same Issue, but await $.native.pressBack() is not an option, because It is not reliable as once it's called, the keyboard does not show up on the next text input.

[javiermrz]

Same Issue, but await $.native.pressBack() is not an option, because It is not reliable as once it's called, the keyboard does not show up on the next text input.

This is exactly what is happening to me.

@fylyppo any news on this? As several mentioned, using the native pressBack is not an option in most cases.

[davidahlstroem]

Here is my temporary fix. Couple it together with a isKeyboardVisible function. More testing is needed to determine what works and doesn't work.

Also, it seems the keyboard only shows up the first time the test tap a widget that calls the keyboard to appear, not the second time. So I only call dismissKeyboard() once ^^

Future<void> dismissKeyboard() async {
    if (!await isKeyboardVisible()) {
      $.log('Keyboard is not visible, nothing to dismiss');
      return;
    } 

$.log('Dismissing keyboard...'); 

try {
      FocusManager.instance.primaryFocus?.unfocus();
      await Future.delayed(const Duration(milliseconds: 500));
      await $.pumpAndSettle();
      if (!await isKeyboardVisible()) {
        $.log('Keyboard dismissed successfully with FocusManager.primaryFocus.unfocus');
        return;
      }
    } catch (e) {
      $.log('FocusManager.primaryFocus.unfocus failed: $e');
    }

try {
      FocusScope.of($.tester.binding.focusManager.rootScope.context!).unfocus();
      await Future.delayed(const Duration(milliseconds: 500));
      await $.pumpAndSettle();
      if (!await isKeyboardVisible()) {
        $.log('Keyboard dismissed successfully with FocusScope.unfocus');
        return;
      }
    } catch (e) {
      $.log('FocusScope.unfocus failed: $e');
    }

try {
      await SystemChannels.textInput.invokeMethod('TextInput.hide');
      await Future.delayed(const Duration(milliseconds: 500));
      await $.pumpAndSettle();
      if (!await isKeyboardVisible()) {
        $.log('Keyboard dismissed successfully with SystemChannels.textInput');
        return;
      }
    } catch (e) {
      $.log('SystemChannels.textInput failed: $e');
    }

[munish-singleops]

Is there any update on this? It’s been a block on iOS, and none of the solutions provided work on iOS. Dismissing the keyboard doesn’t seem to help either.