Element fails after checking with Wait stage

[StevenBrowning]

Version 6.10.3

Background:
The web app that I work with was recently migrated from IE to Edge-Chromium. The BP dev team wasn't made aware of this until they were almost ready to move to production so we are working on a short timeline. We were in BP 6.5 so had to upgrade the environments then try to figure out what changes were needed to make the code work with the new version of the web app.

The new version of the app has inconsistent performance. Sometimes it's really slow, sometimes relatively fast. The original developer had programmed in lots of sleep stages (hard-coded wait times) which worked pretty well with the old app. To deal with the inconsistent performance of the app I have replaced most of the sleep stages with wait stages that check for an element to exist.

Problem:
I am seeing a situation where the wait stage will find that an element exists but the immediately following stage that interacts with that element fails to interact. For instance, There is a screen title in the same place on each screen. I have the wait stage check that the title exists but the read stage says it can't read it (according to the log).

Also, the problem doesn't happen in Object Studio. Usually I would think of a timing problem but the fact that the system sees the element just before it says it can't read it is mystifying. 

The wait stage is set to check for the page title with a timeout of 30 seconds. It is not timing out. The read stage is set to read the text from the same element. I suppose it's possible that somehow the text doesn't exist yet but the element that contains the text does.

Any thoughts or ideas of what could be happening here are appreciated.

[bruce.liu]

Hi Steven,

I have come across a case where a customer uses the parent document loaded of a common element on different pages as the condition for their wait stages. This seems to fit with the scenario you were describing. I suspect when you encountered this issue, the condition you used was checked up alright before the page was navigated somewhere else, but as you perform subsequent read actions, the page was in the process of transiting, therefore the error. In Object Studio you would not likely match the processing speed while having the same object in Control Room, the reason why this issue was difficult to reproduce if you step through the code.

I would personally avoid common elements appear before and after navigation. Is it entirely possible for you to consider a unique element on the page you will eventually navigate to for your wait condition check?

[Devendra_KumarP]

Hi Steven, 
I would suggest in the wait stage instead of "check exists" use condition "Parent Document Loaded" and also retry logic in the process if it fails. hope this will resolve your issue.

[FrankJelstrup]

Hi Steven,

I think Bruce Liu already solved your problem. I just wanted to add to his solution.

I think your problem is that the element exist on your original screen, then you update it to move to next screen, before it gets to load the new screen it find the element and goes thru the wait step, then fails on read as load is a bit further.(What Bruce Liu said in fewer words)

(my addition) If you don't have an unique element you can wait for. Make a wait stage which waits till the element doesn't exist, meaning you are in the process of loading the new page. Then insert a wait stage that waits for the element to reappear, meaning this will be your loaded document. *Takes two wait stages to Tango your problem*

[StevenBrowning]

Bruce, I think you're on to it. As it turns out, there is a standard place for a page title in the app that I'm working with. We check this title to make sure we're on the right page before proceeding. Unfortunately, we don't always know which page will pop up next and we have to navigate through a series of pages (different from run to run) to get to the pages we need. So the original version of the process used hard-coded waits to give the page time to fully load before checking the title. When the client switched from IE to Edge it seemed like an opportunity to streamline things a bit. 

What I realized was that the wait stages worked fine for the pages that had the title text in the spy. But they process was failing when looking for a "generic" title. In these cases all the process could look for was the container for the title since we don't know what text to look for. I suspect that the wait stage was recognizing the container for the title before the text actually existed. Then when the read was attempted there was no text there so it threw and exception.

What I have done is built my own wait stage that catches the read exception, waits 1 second, then tries again for x retries. So far it has worked well and, looking at the logs, haven't seen it go past the second try. This will still be faster than the hard coded waits (some as high as five seconds) but will also allow for inconsistent performance from the app (which I have seen since the switch to Edge).

We have just switched from 6.5 to 6.10.3 for the upgrade to Edge. Perhaps the parent document loaded option is an even more elegant solution to the problem. I was not familiar with it until just now.

Thanks, everyone, for your time and help!

[PvD_SE]

My two cents:
When we recently migrated to Edge IE mode without re-spying everything, we found that some elements at window or document level were still there, but were not exactly the same area as before in IE when highlighted. Re-spying these to cover the same area as in IE fixed the problem.