I’ve just done a new install of Openfire / Spark on Win7Pro and I’m finding precisely the same results as the OP. I have selected pref Bring Window to Front. If the chat is minimised to tray, then everything works as expected and the windows is brought to top. However if it is just hiding behind another window, it does not get brought to the foreground - or at least, not reliably. It does seem to behave every once in a while but these are rare and I can’t see a pattern.
This is an important requirement in corporate environments where the messaging is somewhat time-critical. In our health clinic context, the need is for the front desk to convey an important message to the specialist, who could be examining the patient and therefore miss the temporary Roar/Toast notifications. And they may not be observant or tech-savvy enough to notice the task bar flashing. To be honest my ideal scenario would be that the message sender could designate a particular message as requiring a user acknowledgement, in which case the window to Bring to Front AND Stay on Top until the message is acknowledged (i.e. click OK). From my googling, I am not alone in having this requirement.
But if Bring Window to Front worked, it would help in 95% of situations so that would make the deployment worthwhile.
I can provide a screen capture video showing the issue if that would help.
Happy to perform any kind of required diagnostics.
EDIT:
I figured this out. It is due to a registry setting called ForegroundLockTimeout that sets the time after user activity that windows can grab foreground control. Meant to stop apps from interfering with active users I suspect. Leaving the target computer idle for 200 seconds prior to sending the IM allowed the window to pop up in foreground.Setting the registry value to 0 as outlined here:
made the window pop-up in foreground every time, without the idle user requirement.
At least I understand why it is behaving as it is now.
Message was edited by: micro