Forum Xamarin Test Cloud (Read Only)
We are excited to announce that the Xamarin Forums are moving to the new Microsoft Q&A experience. Q&A is the home for technical questions and answers at across all products at Microsoft now including Xamarin!

We encourage you to head over to Microsoft Q&A for .NET for posting new questions and get involved today.

How to make ClearText work reliably?

I have a page in my app with three Entry controls. In UITest, I have a test that clears the first, puts some text in it, clears the second, puts some text in it, clears the third, puts some text in it.

However... the third ClearText is not working, and so the text being entered is concatenated onto what is already there.

Both the second and third Entry fields are positioned such that they are visible, but when the keyboard appears, if there were no scrolling done, the Entry fields would be hidden. I would assume that ClearText would (should?) throw an exception if it actually thought the third Entry field were not visible, but it does not throw. My suspicion therefore is that in at least two ways, ClearText does not handle properly the scrolling that happens when the keyboard appears. Is this the case? Is there a way to use ClearText reliably (i.e. that does not involve any race conditions) in situations where scrolling might occur when the keyboard appears.

(I am currently testing on a physical Android phone).


John H.


  • DavidLavenderDavidLavender GBXamarin Team Xamurai
    edited August 2015

    Hi John,

    The ClearText() method should do what you are stating above. There are however some considerations to make. If the element does not have focus then ClearText() will not work, it will also not throw an exception. The ClearText() method comes with three flavors:

    public void ClearText();
    public void ClearText(Func<AppQuery, AppWebQuery> query);
    public void ClearText(Func<AppQuery, AppQuery> query);

    If you want an exception to be thrown i suggest you use one of the overloads of ClearText(). In general i would suggest it is best practice to explicitly target the element, this can be done by:

    app.ClearText(e => e.Id("ElementToClear"));

    The keyboard should not effect the function of the above methods but if the element is not currently in view then you will need to scroll to it.


  • JohnHardmanJohnHardman GBUniversity admin
    edited August 2015

    @DavidLavender - Interesting... For the three Entry controls on the page, I was previously scrolling down to the Entry, then using ClearText with the same Marked information as used in the scroll down, before then using EnterText to populate the Entry, before repeating for the subsequent Entry controls. In portrait orientation this was fine, but in landscape it was failing.

    Adding an explicit Tap before the ClearText made it clear what was happening, as well as highlighting a Xamarin.Forms bug that I will raise in bugzilla shortly, a really nasty bit of behaviour presumably in a XF renderer, and a possible bug in UITest.

    On the Android phone that I am using, in landscape mode tapping on an Entry results in that Entry being expanded to fill all of the available vertical space, with a Done button appearing to the side. All very nasty, as per the attached screenshot (the dissociation between the two highlighted areas is what I would deem to be the bug in XF). What made the automated test fail at this point is that despite Repl() saying that this is the app's page rather than some XF created popup, XF has effectively made this Entry modal, which it is not in portrait orientation. One of the consequences of this is that whilst the keyboard remains on display, using ScrollDownTo to get to the next Entry field fails. Scrolling does not work whilst this expanded Entry is present. The really weird thing is that Repl() doesn't seem to show that additional "Done" button, so all I can do to get things working at this point is to call DismissKeyboard() before doing the next ScrollDownTo.

    The possible UITest bug is that Repl() doesn't show that Done button. Although I suppose it could be deemed to be part of the Entry, which would make it not a UITest bug, but just nastiness in XF.

    The whole modal-type behaviour is really nasty. Whilst the user is typing into the Entry fields, validation is being done and reported using Labels that appear beneath the Entry fields. In portrait this is fine, but in landscape the filling of the screen with the Entry field hides the validation feedback. Similar, help text that appears above the Entry in portrait is hidden in landscape. Ugh.

    Thanks again,

    John H.

Sign In or Register to comment.