Handle specific pop up windows

During the Citrix User Path workflow, there may be some unexpected/intermittent windows that appear on the screen (window, dialog, frame, popup, splashscreen…). It could be the case for example for error/warning notification message, prompt to update software or notification scheduled task such as auto-save.

As these windows cannot be expected at a specific time in the User Path execution, some additional design work may be needed in order to reproduce a realistic scenario.

This tutorial is based on a sample application that allows the user to trigger an asynchronous auto-save task, which executes the auto-save and displays a notification dialog after a random amount of time.

Let’s record the Citrix workflow of a user interacting with the application, then randomly gets an “Auto-save” dialog. The user then closes the dialog and continues working on the application.


The below Citrix Actions are recorded by NeoLoad:

  1. A TextType Action for the the first part or the interaction, before the auto-save.
  2. A WindowWait Action for the appearance of the “Auto-save” dialog.
  3. A MouseClick Action to close the “Auto-save” dialog.
  4. A WindowWait Action for the disappearance of the “Auto-save” dialog, when the main window gets back the focus.
  5. A TextType Action for the the second part or the interaction, after the auto-save.

The appearance of the “Auto-save” dialog being random/intermittent, the User Path cannot be replayed as is because there is no guarantee that the auto-save will be performed exactly at the same time during the User Path replay. Depending on the execution pace, the text to type, and the delay of appearance, the notification dialog may be activated earlier, later in a different transaction, or even not at all.

The way to handle this intermittent window is to use a fork logical action inserted as soon as the window could appear. Then, the first WindowWait, the interaction with the dialog (here the MouseClick), and the second WindowWait should be moved inside the fork, to be able to be executed in parallel with the main workflow.


Then, to allow the Citrix Action of the main workflow to be paused until the intermittent window is closed, the “waitTimeoutInMs” parameter of the first WindowWait Action needs to be set to value "0".


Setting the “waitTimeoutInMs” to "0" will produce an infinite wait, and it will block the execution of the main workflow, until the fork finishes its execution.

As a result, as soon as the “Auto-save” dialog is activated, the main workflow (textType) is paused, the fork becomes the only thread active, closes the dialog, waits for the focus to be back on the main window, and then resumes the main workflow with the fork ends. It's important to have the second WindowWait as the last action of the fork, to guarantee that the main thread won't resume until the focus is back to the main window.