search

imzzy / robotium

Automatically exported from code.google.com/p/robotium
0 stars 0 forks source link

Spurious dialog button press when using solo.typeText(.). Not present when using solo.enterText(.). #649

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Launch dialog
2. execute solo.typeText(solo.getEditText(0), subject)
3. Observe dialog button is pressed before text is entered

What is the expected output? What do you see instead?
Expected: solo.typeText(editText, string) should type the string.
Seen: Middle button of dialog is pressed before the string is typed.

What version of the product are you using? On what operating system?
Robotium 5.2.1, Android Studio 1.0.2, Windows 7

Please provide any additional information below.
Debugging line-by-line shows the button press is caused solo.typeText(.). 
However if I use solo.enterText(.) or android's built-in 
getInstrumentation().sendStringSync(.) I don't get this problem.

What steps will reproduce the problem?
1. Launch dialog
2. execute solo.typeText(solo.getEditText(0), subject)
3. Observe dialog button is pressed before text is entered

What is the expected output? What do you see instead?
Expected: solo.typeText(editText, string) should type the string.
Seen: Middle button of dialog is pressed before the string is typed.

What version of the product are you using? On what operating system?
Robotium 5.2.1, Android Studio 1.0.2, Windows 7

Please provide any additional information below.
Debugging line-by-line shows the button press is caused solo.typeText(.). 
However if I use solo.enterText(.) or android's built-in 
getInstrumentation().sendStringSync(.) I don't get this problem.

Code:
    @SmallTest
    public void testCancelButton() {
        launchDialogAndTestShowing(false);

        final String subject = RandomStringGenerator.nextWord();
        final int rating = nextRating();
        final Solo solo = mSolo;
        final DialogAddListener<GvChildrenList.GvChildReview> listener = mListener;
        final RatingBar ratingBar = getRatingBar();
        final DialogCancelAddDoneFragment dialog = mDialog;

        assertFalse(solo.searchEditText(subject));
        assertEquals(0, doubleInt(ratingBar.getRating()));
        assertNull(listener.getData());

        //solo.enterText(solo.getEditText(0), subject); //this is ok
        //getInstrumentation().sendStringSync(subject); //this is ok
        solo.typeText(solo.getEditText(0), subject); //cause spurious button press...
        solo.setProgressBar(0, rating);

        assertTrue(solo.searchEditText(subject));
        assertEquals(rating, doubleInt(ratingBar.getRating()));
        assertNull(listener.getData());

        mActivity.runOnUiThread(new Runnable() {
            public void run() {
                dialog.clickCancelButton();
                assertNull(listener.getData());
                assertFalse(dialog.isVisible());
            }
        });
    }

Original issue reported on code.google.com by rizwan.c...@gmail.com on 7 Jan 2015 at 2:03

GoogleCodeExporter commented 9 years ago 
I think it maybe connected with the soft keyboard's return key perhaps? I have 
changed the IME options on the keyboard from a "return" key to a "go" key which 
executes the middle button of the dialog. Looks like typeText resets the soft 
keyboard to show a return key somehow pressing the go key in the process before 
typing in the text.....?

Original comment by rizwan.c...@gmail.com on 7 Jan 2015 at 2:11

GoogleCodeExporter commented 9 years ago 
This is a known Android bug with dialogs. Sometimes the views shown in the 
dialog return incorrect coordinates. The way typeText works is that it asks the 
EditText view where it is located, then it clicks the View (to support 
Expandable ListViews) before sending the text string. Due to the Android bug 
the EditText will sometimes report incorrect coordinates which leads to the 
wrong View being clicked which leads to issues similar to yours. Unfortunately 
there is nothing we can do about this. In dialogs its advised to use enterText 
instead.

Original comment by renasr...@gmail.com on 9 Jan 2015 at 9:31

GoogleCodeExporter commented 9 years ago 
Ok many thanks for your reply

Original comment by rizwan.c...@gmail.com on 9 Jan 2015 at 9:34