Bring window to front problems

I just upgraded all the hardware in my office from xp desktops to Windows 7 x64 laptops and now I’m having user complaints that spark does not behave the same as it did before. Specifically the notification window does pop up in front of all other windows UNLESS there is no current chat window open or the chat window is minimized to the task bar. I have a few older PCs still in use and they behave the same way as the new ones, the message window DOES NOT pop up in front if it is not minimized or closed (it is a window behind another window). Everyone claims this is NOT how spark was before the upgrade so the only thing I can think of that would effect the new and the old PCs is the fact that I have already upgraded java to v6u24 on the old PCs and it is the only java ever installed on the new PCs.

I do have the “Bring window to front” checked in Preferences.

New Laptop Properties

OS: Windows 7 x64

Spark: 2.5.8

Java: Version 6 Update 24

Server Properties
Server Uptime:
17 hours, 45 minutes – started Apr 19, 2011 6:21:32 PM
Openfire 3.7.0

Java Version:
1.6.0_18 Sun Microsystems Inc. – Java HotSpot™ Client VM

OS / Hardware:
Windows 2003 / x86

…also we don’t get any toast pop ups after the first one until you make the spark chat window active.

Wolf has created a ticket SPARK-1291 though this need to be tested with the latest 2.6.0 RC2 version park_2_6_0_12222.exe

ive already seen that behaviour and created a ticket

probably know already where its coming from, will patch in coming week

Has this been patched yet? If so where could i get this patch? This issue is causing important messages to be missed due to the window not being brought to the front. Please help.

yes this was adressed ( SPARK-1291 shows you the bugticket)

the newest versions can be acquired by visiting:

then clicking on “Latest Status: SPARK-INSTALL4J-XYZ was successful” in the top right corner

then clicking on “Artifacts”-tab and you will see:

User-Defined Artifacts

The build has the following artifacts.

  • Install4j (97 MB)

I am still unable to get this to work correctly. If the chat window is NOT minimized it will not come to the front when a new message arrives. I have downloaded the " spark_2_6_3_12555.exe" file, but it still isn’t working. Any suggestions. I am obviously new to this so I apologize if the answer is right in front of me and I am not seeing it.


Can’t reproduce. For me “bring to front” works as it should.

So it brings it to the front even when the window is “up”, but behind another window? I have tried on multiple machines with both XP and 7 on them. And it only “bring it to fron” when the chat window is minimized.

I was testing locally with two clients. So when i was typing in another client, Spark window was in background. You can give a try to this installer (the most recent version from the svn) l4j

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.


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

1 Like

Good finding. After playing around with two clients (one of them Win7 x64) i have noticed that this timeout function only kicks in if you are interacting with other applications. E.g. you get a message and a window jumps in front. If you close it or minimize it, then next message will still bring it up in front even without waiting 200 seconds. But if instead you click some other app, say browser, then new messages will just blink in the taskbar without bringing the window up in front. Then after 200 seconds of idle new message will bring the window up again.

All of which leaves me with the following comments:

  1. The behaviour makes me wonder how Roar can seemingly override the registry parameter, as it is always brought to foreground regardless of recent user activity, and whether this can be applied to the chat window Bring to Front functionality.
  2. In looking more closely at the Roar settings, it is nicely configurable and will basically meet the requirement I outlined in my previous post, by putting say a 30 minutes (= 1800000 ms) in Spark -> Preferences -> ROAR -> Duration in ms). Now the notification will persist for 30 minutes providing ample opportunity for our specialist to glance at the screen and action the request (generally it is just to temporarily release a patient record so the front desk can update client details in preparation for invoicing). Of course I may have to revisit this if it drives everyone nuts, but I think we can avoid that with usage tips/policies.
  3. It would be nice if ROAR could be configured to leave the popup on-screen indefinitely, perhaps by configuring Duration in ms = 0. In other words, the window would persist until the user clicks the popup. How it works right now: if you configure Duration = 0, save and re-enter preferences, the parm has been reset to 3000 ms. While this is not a terribly important option in my context, I can see how it would be very useful for others and it seems like it would be fairly easy to implement (famous last words).
  4. More important, however, would be the ability for the message sender to mark only particular messages as requiring user acknowledgement or a long notification period. Alternatively, the admin or the recipient could set notifications from a particular room or user(s) to be different to others. An example might help, following on from the scenario I mentioned above: notifications from the front desk would receive priority notifications, i.e. ROAR for 30 minutes. However a chat room message would just do a normal toast popup as it would be chat, not an action-is-required scenario. Right now I plan to limit our use of Openfire/Spark to the urgent notification paradigm, as that is our greater business need, but ideally I would also be able to also use chat in a more collaborative way. Yes, I want to have my cake and eat it too.

Anyway those are my thoughts. Happy to post suggestions elsewhere if there is a more appropriate place.

Openfire/Spark is a FOSS at its best - I am impressed and grateful to the dev and wider community.

This is the appropriate place to post suggestions.

  1. Roar is probably using some other window style (popup, tooltip), so the timeout option doesn’t apply to it. Not sure if it can be used for the chat window. But i’m not a developer myself. Looking through the Roar’s source i see RoarPanel.popupWindow function used.

  2. As a workaround you can set it to say 30000000 and it would stay almost indefinitely. Though i haven’t tested, but it saves such a value. Of course, having it using a 0 for this would be more convenient/understandable. SPARK-1595. Though Roar’s developer is not active in the community/project anymore, so i can’t say when/whether anyone will look into this.

  3. This sound too complex for a simple chatting program and a popup plugin (and even above the xmpp specifications: sending additional type information with the message). Having different settings for group chat and general chats sounds reasonable. SPARK-1596

i created a patch and issued a pull request

Hi, Wolf. Nice to hear from you wonder who will approve the pull. Walter is still assigned as a lead, but i’m not sure if he still doing this and an approves requests. Btw, which ticket is your patch for? Or both?

if you set roar time to 0 it will stay until clicked

so not fixing the bring-to-front problem :wink:

wonder who will approve the pull.
That’s indeed a problem. Spark currently has no assigned maintainer. No one is taking care of it.

Walter is still assigned as a lead, but i’m not sure if he still doing this and an approves requests.
Haven’t heard from him in months.

Wolf’s PR merged by Konstantin Spark - INSTALL4J 666: Build result summary - Atlassian Bamboo

I know it has been a while since you created requirements SPARK-1595 and SPARK-1596 on my behalf. First of all: thank you for listening.

SPARK-1595 speaks for itself and thanks to Wolf for acting on it.

SPARK-1596 however, I think could perhaps benefit from reconsideration. You see - I had an idea that I believe could help create a rather clever solution to the problem. First let me reiterate the business issue in a very generic sense: some users might want some messages to be notified more prominently than others. I can think of all kinds of corporate contexts for that generic need. I appreciate, however, that in the IM world it must be difficult to agree on implementations that require code changes on both the sender’s and receiver’s device. Therefore I propose that this be handled entirely within the receiver’s client (in my case Spark). Here is how it could work:

  • The receiver has a standard notification configured as it currently works. This would be the non-urgent case. For example, ROAR might not be used for most messages.
  • However, there is also a configuration setting to specify a string in the message that would trigger a different notification. For example, if the receiver sets this string to be #URGENT# then whenever this string is included in the message text by the sender (which is simply a corporate procedure, not anything built into their IM client per se) then the ROAR notification is triggered.

To me it seems elegant and hopefully not too difficult to implement. It seems easier and more useful to me than the current reading of SPARK-1596. With this approach I do get to have my cake and eat it: users can participate in non-intrusive conversations, but urgent notifications are available on an exception basis. It also does not rely on a distinction between group vs individual chat, and realistically urgent notification could be useful in both contexts.

That’s my suggestion.