I have observed this under Slackware 14.2, running Xfce 4.12. The bug results in a desktop that is unresponsive to any mouse or keyboard events. The only way I have found to get out of such a state consists of killing the X session, or even rebooting the system.

Steps to replicate it:

1. Create a launcher in one of the panels - I usually do so in my top panel.
2. The launcher should run a command that attempts to prompt for a password. In my case, my launcher executes the following command:

      ssvnc -cmd -ssh remote-system:0 -passwd $HOME/.vnc/passwd > /dev/null 2>&1

3. Make sure that the "Run in terminal" box is NOT ticked in the launcher properties.

    The ssvnc command above just attempts to establish an SSH tunnel to remote-system, and then access the desktop at the console in remote-system through this tunnel. The password to be supplied to the VNC server in remote-system is obtained from $HOME/.vnc/passwd.

    This ssvnc command implicitly assumes that remote-system can be accessed without having to supply an SSH password (note: the VNC password above is totally unrelated to this password.) When such is the case - like e.g. when using public key authentication - the tunnel is created without any problems and the remote-system desktop is accessed through it.

    Now imagine that ssvnc actually attempts to prompt for a password - this will happen e.g. when public key authentication is meant to be used, but the required, matching private key has not been added to the local SSH agent. In this case, when clicking in the launcher above, ssvnc will pause, attempting to issue the password prompt. However, since "Run in terminal" was not ticked in the launcher, ssvnc can't issue the prompt. At this point a deadlock ensues. The user-visible outcome is that the desktop environment becomes unresponsive. Applications already launched may still be running - for example, terminal emulators already present will not suddenly freeze (I think). However, XFCE apps will - for example, I have a number of items in top panel (like a clock, CPU activity monitoring, network activity monitoring, etc.) that visibly freeze. The pointer can still be moved around, but any mouse clicks are ignored. Likewise, any events from the keyboard are ignored. For all practical purposes, the desktop is locked up. 

   I have traced this to the xfwm4 window manager. When this state is entered, xfwm4 can be killed (from a VT or an SSH connection) but the desktop can't be really recovered, in that everything (e.g. whatever terminal emulators that one might have) are all jumbled up and not really accessible - there is no window manager, for xfwm4 does not restart automatically after having been killed - at least not in the situation I am describing.

   I have not been able to find a way to recover from this situation that does not involve restarting the X session, or even rebooting the system. Perhaps surprisingly, killing the processes spawned by ssvnc does not unlock xfwm4. 

   This situation may be avoided in two different ways. First, the launcher can be configured so that "Run in terminal" is ticked. In this case, when launched a terminal emulator will be spawned, which implies that, if a password prompt is to be issued, it will appear in the emulator. The second way consists of configuring the SSH connection to remote-system with the BatchMode feature, which implies that one will be never be prompted for a password when attempting to connect with remote-system over SSH.

   It would seem preferable to try to change the behavior of xfwm4 so that it will not lock up - it should not be possible for external applications to cause xfwm4 to enter a hard lock up condition as described here.