Hi all, For me on Windows Vista, in DrRacket, the tool-tip pop-up text disappears, and the pop-up's background is incorrectly cleared, when the mouse cursor enters the tool-tip text area. I have the toolbar on the left ('view' -> 'toolbar' -> 'toolbar on left'). I hover the mouse over one of the tools in the toolbar, and after the tool-tip has popped up, I move the mouse cursor into the tool-tip text area, and the tool-tip text is removed and the background is reset to some default(?) value. (Reported as [racket-bug] all/12562: Toolbar tool-tip issues). Note that the tool-tip text is now persistently set for that current DrRacket tab and all new tabs created from the current tab. I noticed this problem with tool-tips text being cleared started manifesting in the nightly builds at about the time the running widget started, well ... running. And I also noticed that the problem was absent in the nightly builds when the running widget was briefly returned back to its old (version 5.2) non-animated self. Can anyone replicate this issue? Or have I messed up my install some how? This might be some sort of memory leak, or perhaps some sort of race condition with the order of clearing and painting. But at the least it is a problem visually. And the visual problem is exacerbated, when it is combined with tool-tips not always disappearing when they mouse focus is shifted away from DrRacket to a frame it has started. i.e. Under some circumstances, a frame created by DrRacket appears between (in z-order) DrRacket and the (bad) tool-tip, since tool-tips are always on top. Tool-tips should time-out after some number of seconds and disappear regardless. But instead they sometimes hang around when the tool-tip's owner has lost mouse focus, and are only cleared after the parent receives focus again. BTW: The tool-tips not disappearing (corrupted or not) thing seems to be a Windows (Vista?) thing. I see it with 'system' GUI components too. It might be due to some GUI events (e.g. mouse focus lost) being held in a queue and not processed until some (mouse or keyboard) focus is returned back to the parent. Cheers, Kieron.