Locator property 'contains' no longer works in 6.3.x

As of 6.3.x, it appears that ‘contains’ in the object properties seems to not work in the same way it did before. An example I have is that my text for an object will contain a particular word/phrase. In previous versions, I could just have the word/phrase as contains and the object would be located. As of 6.3.x, it seems that the object properties now requires more in order to find the object - ie add’l spaces and words rather than allowing just the one particular word/phrase. This has caused rewrites to current tests that were working prior to the 6.3.x release.

image

The contains object condition is working fine for me (v6.3.3). Try using absolute equality or alternatively use regular expressions if you must use partial equality.

@ThanhTo @duyluong

  1. Was there a change between 6.2.x and 6.3.x that might account for this behavior?

  2. Can we get some traction on this? (A broken UX in this part of the UI should be fixed and uplifted to 7.x, don’t you think?)

1 Like

Hi @Amanda_Perkins1

I will look into this and let you know.

Cheers !

2 Likes

Hi @Amanda_Perkins1

Can you give me a use case where this problem surfaces ? How did things go in 6.2.0 ?

Cheers !

I used to be able to use text contains save if the button had the text ‘save’ in it. Now, the button has changed to have leading and trailing spaces around the text ‘save’ and the locator will not find the button based on ‘contains’. I had to change the text to equals and then copy and paste the text of the button, with the leading and trailing spaces, into the text field.

So, for me, the ‘contains’ is no longer working as it is requiring me to use ‘equals’ and have the entire string with spaces to locate the object.