Cannot always detect repo-items if PopupWatcher is running

[uhmdown]

Hi,

I'm am struggling with what seems to be a bug in Ranorex.

I have a repo item that I want to access, but before that I launch a PopupWatcher.

The thing is that I know the repo-item Xpath is correct (RanorexSpy and Ranorex Suite have no problems), when I have deployed it to an agent running in VMware, the repo item doesn't get detected. This is even though the PopupWatcher doesn't get triggered (the item-info it's watching doesn't appear).
When I try with the Spy immediately afterwards (even when the Agent is still struggling to detect the repo item), it works a.

If I comment out the line that starts the PopupWatcher, then the repo item get detected with no problems.


So this must be a bug in the PopupWatcher.
Has anybody else seen this ?

[odklizec]

Hi,

Nope, I never experienced anything like this with popupwatcher. It would be helpful, if you could post a Ranorex version you are using, snapshot of the problematic element and xpath you are using in repo/popupwatcher code. Without these details, it's next to impossible to suggest something reliable.

[uhmdown]

Ok, I had an idea about why it might be failing, and it turned out to be right.

The issue has something do with launching the Software-under-test as Admin.

If I launch it without admin, then Ranorex has no problems with it. But if it is launched as admin (I direct the RemoteAgent to perform a rightclick on the SUT icon and select run as admin), then the PopupWatcher blocks all object recognition.

Interestingly, the RemoteAgent doesn't show any warning message about admin rights.


It happens on 7.1, and it still happens after I upgraded to 7.2.1.

[odklizec]

Of course, if you run the app under test as Admin, you must run Ranorex Studio/test as Admin too! Ideally, you should always start Ranorex Studio as admin to have enough rights to access AUT UI.

[uhmdown]

Ah, but Ranorex Suite or Spy have no problems with the SUT running as Admin (I always run them as Admin).

But what about the RemoteAgent that I'm deploying to (a VMware running on a different PC)? It only happens when I'm using a Remote Agent that launches the SUT as Admin.

Infact, even if I manually launch the RemoteAgent first as Admin, it still causes the PopupWathcer to block object recognition.

[odklizec]

Ahh, sorry, I'm not using Remote Agent for Ranorext test distribution (I'm using Jenkins). So I can't comment this. But it sounds like a problem with remote agent then?

[uhmdown]

It could be the Remote Agent, but I'm leaning towards the PopupWatcher.

Because if I don't start a PopupWatcher, then the deployed TestSuite has no problems detecting any Repo items.

[odklizec]

The truth is, that popupwatcher is running in a separate thread from main test thread. So the question is, if that second thread is running with enough privileges?

[krstcs]

Actually, my guess would be that this is a timing issue due to the popup-watcher being in its own thread. On VMs the timing can be worse than expected due to the VM not getting resources the same way a hard-iron system does. Try putting a pause in the test right before the item that is not being found and see if that helps. Even a half-second delay may be enough for the popup-watcher to do it's thing and then allow the system to find the element.

If that doesn't help, then it might be a bug in the Remote Agent. The issue here is that if it works in Ranorex Studio locally, but not in the agent, it isn't likely a bug with the popup-watcher, but with how the Remote Agent is working with the remote system and user account control/level.

[uhmdown]

I tried putting delays all over the code, up to 10 secs. Didn't help.
Also turned out that it happens even when the SUT was launched without admin by the Agent; I just got lucky that time it worked. So that theory falls flat.

But yeah, I think you're right. Something with the PopupWatcher running in its own thread + the RemoteAgent is breaking somthing.

I'll update when I hear from Ranorex support.

[uhmdown]

Ok, I was playing around with this, and I actually managed to find a workaround.

Immediately after starting the popupwatcher, I was accessing repoitem that xpathed to an icon on the desktop (to launch the SUT), and then object detection froze.
But simply starting the PopupWatcher after having accessed the icon repoitem solved it. Now it just works, consistently. I didn't even need most of the delays I had placed around the PopupWatcher startup code.


I have no idea why this would fix it. But def gonna add that to my list of Ranorex quirks.