Open GoogleCodeExporter opened 9 years ago
GoogleCodeExporter
commented
9 years ago Is it a consistent repro? (we rarely test on physical devices, but I can try
this out if it's easy to reproduce).Original comment by vale...@google.com on 9 Jun 2014 at 9:59
GoogleCodeExporter
commented
9 years ago As mentioned above, I am also able to reproduce this on an emulator. It is not
100% consistent, however it is consistent enough that I had to add a 500
millisecond sleep after every call to closeSoftKeyboard() in order to make my
tests reliable.
If you follow the thread in
https://groups.google.com/forum/#!searchin/android-test-kit-discuss/keyboard/and
roid-test-kit-discuss/IX-D3BRWQsE/-XAQmW9HrRMJ, R Palan mentions that he
specifically had to configure the emulator to "hardware keyboard present" as a
workaround, meaning that he was also able to reproduce this on an emulator.Original comment by mhernan...@gmail.com on 10 Jun 2014 at 4:22
GoogleCodeExporter
commented
9 years ago I find that on older devices, like the Samsung SIII Mini, this happens quite
regularly. I'd say a given test has a 50% chance of failing.Original comment by stern....@gmail.com on 21 Jul 2014 at 10:11
GoogleCodeExporter
commented
9 years ago I found the best work around is to use @FlakyTest(tolerance = 5), which will
tell the instrumentation test runner to try a x times before marking the test
as failed.Original comment by stern....@gmail.com on 21 Jul 2014 at 10:36
GoogleCodeExporter
commented
9 years ago [deleted comment]Same problem here. Need to wait for the keyboard to close. Just because the RPC
call returned fast the UI is still blocked by the keyboard.
Sleeping seems the ugliest but the only solution that works.Original comment by dnkoutso@gmail.com on 24 Jul 2014 at 6:46
GoogleCodeExporter
commented
9 years ago In the meantime, I wound up implementing my own wrapper closeSoftKeyboard()
ViewAction like so:
public static ViewAction closeSoftKeyboard() {
return new ViewAction() {
/**
* The delay time to allow the soft keyboard to dismiss.
*/
private static final long KEYBOARD_DISMISSAL_DELAY_MILLIS = 1000L;
/**
* The real {@link CloseKeyboardAction} instance.
*/
private final ViewAction mCloseSoftKeyboard = new CloseKeyboardAction();
@Override
public Matcher<View> getConstraints() {
return mCloseSoftKeyboard.getConstraints();
}
@Override
public String getDescription() {
return mCloseSoftKeyboard.getDescription();
}
@Override
public void perform(final UiController uiController, final View view) {
mCloseSoftKeyboard.perform(uiController, view);
uiController.loopMainThreadForAtLeast(KEYBOARD_DISMISSAL_DELAY_MILLIS);
}
};
}Original comment by mhernan...@gmail.com on 24 Jul 2014 at 8:11
GoogleCodeExporter
commented
9 years ago I worked around this problem by implementing my own keyboard that is only 32dp
tall that I use on testing devices.
https://github.com/johnybot/TestingKeyboardOriginal comment by johnatha...@hootsuite.com on 28 Jul 2014 at 8:59
GoogleCodeExporter
commented
9 years ago Is this something that happens even when system animations are turned off?Original comment by vale...@google.com on 19 Nov 2014 at 9:39
GoogleCodeExporter
commented
9 years ago Yes. I was running into this with all three system animations off.Original comment by mhernan...@gmail.com on 21 Nov 2014 at 7:22
GoogleCodeExporter
commented
9 years ago I also was running into this with animations turned off.Original comment by stern....@gmail.com on 21 Nov 2014 at 3:09
GoogleCodeExporter
commented
9 years ago I didn't use Espresso 1.1. I tried Espresso 2.0 and I'm running into this with
all three system animations off (I think keyboard dismiss animation is not
affected by these options).
The bug can be reproduced using your own tests (lanscape mode), Google Keyboard
and:
Nexus7 (2012), Android 5.0.2
Nexus5 - Android 5.0.1
I opened an issue there:
https://github.com/googlesamples/android-testing/issues/5
It's not an invalid issue, otherwise Espresso 2.0 does not support real devices.
https://code.google.com/p/android-test-kit/issues/detail?id=44
I understand that the idea is to use emulators, CI servers and cloud but I
thought your test kit supports real devices to confirm results.
KEYBOARD_DISMISSAL_DELAY works to slve the issue and demostrate it.
Original comment by ard...@gmail.com on 28 Dec 2014 at 6:50
Attachments:
GoogleCodeExporter
commented
9 years ago I'd forgotten about this issue. I haven't upgraded to 2.0 yet, but for 1.1, I
put together a custom ViewAction to close the softkeyboard that synchronized on
a somewhat shady detection of the keyboard being removed. I haven't had time to
clean it up or test it in 2.0, but if it'll help someone in the meantime or if
someone can add some proper testing for it, I've attached my source class.
There were still occasional failures that I never had a chance to track down,
but it occurred so infrequently that it didn't affect my testing overall. It
may not be production ready per se.Original comment by p.pr...@blueesoteric.com on 28 Dec 2014 at 7:32
Attachments:
Original issue reported on code.google.com by
mhernan...@gmail.comon 3 Jun 2014 at 7:15