Ranorex Forum

I have following questions regarding PopupWatcher:

• 1. Does it stops execution of UI actions (mouse moves and clicks) in the main thread while executing PopupItemCallback?
  
  2. Does it have any way to determine which PopupItemCallback to execute when several pop-ups are detected (so that different pop-up handlers do not interfere each other)?

Why do I have such question:
I have test automation for web application that uses Java plug-in.
Before logging in to the application I close Java security warning dialogs with marking of Do not show again check box (I have 'Do you want to run this application and 'Allow access to this application' dialogs).
Nevertheless during execution of tests on Lab machines in approximately 20% of cases I have 'Allow access to this application Java dialog popping up again (even multiple times). Popping up of Java security warning furthermore results in appearance of web browser's Unresponsive script dialog (see screenshot in the end). Important thing with Unresponsive script pop-up is that it is blocked by Java pop-up - so that to close Unresponsive script dialog 'Allow access' Java security warning dialog should be closed first.

Previously I used my own watcher for pop-ups but refused it due to following reason:

• Pop-up dialog windows are implemented with Java and so recognized and handled slowly - which is performed in the separate thread. In the same time main test screnario is executed in the main thread invoking mouse actions which though not being effective activate window of Web Browser and hide Java Security warning window preventing it from closing by my pop-up watcher.
  
  Problem was: Mechanism to suspend mouse actions performed by Ranorex in the main thread (and in threads of watchers that close blocked pop-ups) is required to handle pop-ups effectively.

What documentation on PopupWatcher I have found so far
http://www.ranorex.com/support/user-gui ... html#c4678
http://www.ranorex.com/Documentation/Ra ... atcher.htm


Screenshot

To answer you 2 specific questions:

1. Not by itself. The popup watcher runs in a separate thread and does not monitor the test thread. All it is designed for is clicking on UNEXPECTED modal-type dialog or error buttons that might popup randomly during testing. It is not designed for expected dialogs, see below*.

There are ways to work around this in code, but they require a lot of work. For instance, you could create a global variable in the test's Program.cs that is used as a flag for test continuation. The popup watcher would set it to false to pause the test, and back to true when ready to continue. However, this means that EVERY test module will have to contain user-code that handles these pauses.

*I would suggest that if you have dialogs that you know will, or even might, pop up during your test, you should code the test accordingly and not rely on the popup watcher mechanism. For example, if you know that a certain popup will be displayed if you enter an invalid SSN or password, you could add the actions to handle that specific dialog in the place they should happen, but then wrap that action in a user-code "if" statement, with the if's condition being based on the input SSN or password. This is a better, and more correct, way to handled expected, but rare, dialogs.


2. Yes, when you create the watcher you tell it which repository item or XPath to use for identifying when it needs to run. Sometimes you can use the same watcher for multiple popups, sometimes you will need to create multiple watchers, which all run independently of each other).

Problem is that dialogs I have are really unexpected - first they pop-up at random step in test script, second they should not pop-up at all (as I close them at the beginning of test script - where they are expected - with 'Do not show again' check box marked).

The work around you have suggested is really difficult to implement as any call to Ranorex method that affect UI should be updated (enclosed in some kind of if or replaced with some wrapper). It is not as complicated as needs extensive amount changes in test code. I would suggest implementing a fix in Ranorex libraries which is nearly the same as work around you have suggested:

As PopupWatcher is implemented in Ranorex libraries - it is possible to implement fix in it for situations when main thread's test code prevents pop-up handler from closing pop-up dialog.

Fix can be implemented in following way:

• - When PopupWatcher detects any pop-up - it sets certain 'global block flag' to true, starts handler of that pop-up in separate thread and adds that thread ID to 'global pop-up handler thread IDs list' (both 'global block flag' and 'global pop-up handler thread IDs list' should not be exposed to users of Ranorex API)
  - All Ranorex methods that perform any action with UI (Click, Activate window, Maximize... - all methods that affect UI in any way) - before starting UI-action check 'global block flag' (from previous item) - if flag is set to false - they proceed with action, if flag is set to true they do not perform action and start to wait for flag to become false and meanwhile perform following:
  - After each Ranorex UI affecting method have detected that 'global block flag' is set to false - it starts to look into 'global pop-up handler thread IDs list' maintained by PopupWatcher (which should be a singleton) in following way:
  - Each UI-affecting Ranorex method determines if its thread ID corresponds to 'highest priority' thread from 'global pop-up handler thread IDs list' that is maintained by PopupWatcher and depending on result performs the following:
  - If thread of certain 'Ranorex UI-affecting method' appears to be 'highest priority' thread from 'global pop-up handler thread IDs list' - method gets executed normally (as if 'global block flag' was set to false), so that all 'Rarnorex UI-affecting methods' of 'highest priority' thread get executed one by one resulting into the following:
  - After all code of 'highest priority' thread (according to 'global pop-up handler thread IDs list') is executed and thread exits - PopupWatcher removes its ID from 'global pop-up handler thread IDs list' which results in execution of 'Ranorex UI-affecting methods' in next thread from that list (and that next thread becomes in turn 'highest priority' thread) so that all threads from 'global pop-up handler thread IDs list' get executed one by one - and then:
  - After all threads from 'global pop-up handler thread IDs list' are executed and list becomes empty - PopupWatcher sets 'global block flag' to false again - and Ranorex UI-affecting methods from the main thread proceed execution until next pop-up is detected by PopupWatcher
  
  Also: When dialog is being added to PopupWatcher it should be possible to specify parameter flag (bool parameter) that determines whether to look for dialog once - or infinite number of times. That is - when dialog is detected and handled then - according to new parameter value PopupWatcher will either stop looking for dialog or will start looking for dialog again (to execute handler each time when it detects dialog).
  
  It will also make sense to add timeout (internal and/or user defined) for completion of thread from 'global pop-up handler thread IDs list' - after timeout exceeds thread gets terminated.

If you have read till the end - you are really a hero. If you have questions regarding a concept I have suggested - please ask either on forum or via private message.

I would suggest that you need to file a bug report with your developers for the issue of popups not honoring the "Do not show again" checkbox. This seems to be the problem, and if it is blocking your tests, you need to tell the developers and your/their bosses so that this gets fixed. It you are having problems with it then customers will as well (and I would say that to them, so they understand it isn't just a "test thing").


I would also suggest that if you want to send a feature request to Ranorex you should email it to [email protected] for evaluation and discussion. They prefer those things be done via email and not in the forums.

Thanks for advice about submitting feature request by email to support(at)ranorex.com.

The reality is that development team has pretty heavy defects load and simply neglects minor defects - especially this one which has Java's dialogs popping-up - not those displayed by the product itself.

While defect remains unfixed I have problems with test results statistics picture and have to make up work-arounds for the problem - to make sure other product functionality gets covered by test automation. And for reliable work around a functionality like described above is required. That's why implementation of the feature I have described is really important to me and is in general a mature fix for situations of such kind.

Hi AKalytiuk,

Thank you for the feature request. We will discuss this problem by email.

The forum post will be updated as soon as we were able to resolve the problem.

Regards,

Markus (S)