Solo.clickOnButton() does not work in some cases

[GoogleCodeExporter]

When using a dialog that contains an EditText, the dialog has two positions:

1. The dialog appears in the center of the screen. No soft keyboard is shown.
2. The soft keyboard appears and the dialog is shifted up. This means that the 
keyboard takes up the bottom half of the screen and the dialog is displayed 
above.

The following occurs when testing a dialog that contains an EditText and a 
Button. We have code that automatically displays the soft keyboard before the 
dialog appears (by calling inputMethodManager.toggleSoftInput) so that the user 
doesn't have to click on the edit text to open the keyboard. 

What steps will reproduce the problem?

1. A dialog opens with an EditText, for which the soft keyboard opens 
automatically. This means that the dialog is already in the "shifted up" 
position.
2. Call Solo.clickOnEditText() to gain focus on the edit text
3. Call Solo.enterText() with some text
4. Call Solo.clickOnButton()

What is the expected output? What do you see instead?

Expected:

4. The button is clicked on.

Actual:

4. The area above the button is clicked on. 

What version of the product are you using? 

Robotium 3.3

Please provide any additional information below.

The reason why this occurs is because Clicker.clickOnScreen() relies on 
View.getLocationOnScreen() and this does not work for this particular case. If 
a dialog is shifted up when the keyboard is shown, or shifted back down when 
the keyboard is dismissed, View.getLocationOnScreen() will return the same 
coordinates for both positions. The initial position - i.e. the position the 
dialog was in when it was created - seems to be the position that is "locked" 
in. Calling getTop() or getBottom() also return the same value, no matter 
whether the dialog has been shifted vertically or not. This appears to be a bug 
in Android (we are using 2.2) and not a problem with Robotium.

In our particular case, since the dialog was shown AFTER we forced the keyboard 
open, the dialog appears above the keyboard and the dialog's internal position 
is set to the "shifted up" position. When in step 3. we call Solo.enterText(), 
this in turn calls TextEnterer.setEditText, which hides the keyboard via 
closeSoftKeyboard(). Closing the keyboard shifts the dialog back down, and, 
since its internal position is still set to the "shifted up" position, the 
coordinates are wrong. Attempting to click on the button in step 4. will obtain 
incorrect coordinates and click on a y coordinate closer to the top of the 
screen.

Commenting out closeSoftKeyboard in TextEnterer.setEditText solves the problem 
for us, since all of our dialogs with EditTexts automatically show / hide the 
keyboard. However, this solution does not work for the more common case where 
the keyboard does NOT appear until the user has clicked on and focused the 
EditText, because its initial position is set to the center of the screen, 
making it necessary to dismiss the keyboard before the dialog can go back to 
its original position.

One possible solution could be to detect the initial state of the dialog, and 
only hide the keyboard if necessary. However, I'm sure there is something here 
we don't fully understand, since the behavior of View.getLocationOnScreen() is 
very odd.

Original issue reported on code.google.com by mjac...@gmail.com on 23 Jul 2012 at 2:28

[GoogleCodeExporter]

Thanks for reporting this. Unfortunately I do not think it is possible to know 
if the soft keyboard is up or not. So it is not possible to implement a 
behaviour based on that. Also there is an issue with getLocationOnScreen() as 
one would expect it to return the correct current position. 

This is a valid issue and will be accepted. I am not sure right now how it can 
be solved (with the current behaviour of getLocationOnScreen() and not knowing 
when the soft keyboard is up). Lets see if we can find a way to solve this 
issue. 

Anyone with ideas please share them here.

Original comment by renasr...@gmail.com on 25 Jul 2012 at 11:22

• Changed state: Accepted

[GoogleCodeExporter]

Will open up again if a solution is found to this problem.

Original comment by renasr...@gmail.com on 7 Aug 2012 at 8:53

• Changed state: WontFix

[GoogleCodeExporter]

For anyone who is also having this problem, I came up to the following 
workaround.

Solo.enterText(0, "textToEnter");
final Button myOkButtonWithinTheDialog =  Solo.getButton(0);
try {
   runTestOnUiThread(new Runnable() {
      @Override
      public void run() {
         myOkButtonWithinTheDialog.performClick();
      }
   });
} catch (Throwable throwable) {
   throwable.printStackTrace();
}

Original comment by JoaRe...@gmail.com on 4 Jan 2013 at 2:54

[GoogleCodeExporter]

Thanks for the workaround. That worked for me.

Original comment by gabriel.kb on 14 Jan 2013 at 7:14

[GoogleCodeExporter]

Issue 431 has been merged into this issue.

Original comment by renasr...@gmail.com on 10 Apr 2013 at 12:01