Will come up with a cs for the issues in Morphic widgets shortly after I test them more thoroughly.. I am kind of convinced that putting a breakpoint in a method with "Toggle Breakpoint" and then stepping through the morphic code base is causing the UI instability of rendering glitches and other concomittant issues. It does not occur, if we do normal "debugIt" and then step through, so it should not be much to do with Morphic stepping thru logic of events et all.. but something intrinsic to how the breakpoint affects Morphic / UI rendering of Pharo. I have done fair amount of work spread across several days with the same image earlier, days prior to "breakpoint" capabilities on Pharo 1.1, but now I barely have the image last the day, goes sluggish and with these UI blemishes may be unrelated but I suspect a correlation: ( Pharo is Lot better though than Linux blemises with Compbiz where you loose all window bars, decorations.. once a while..!) On Pharo 1.3 stable mostly/ Also Pharo 1.4 latest : * The thumbnail image of taskbar windows will remain painted, behind the top window, on the World.. ( thankfully..) but at times on front occluding the top window . * Windows/ Menus will come up partially occluded and running the mouse over exposes it fully.. * Mouse inputs become sluggish... * Transcript opened in these situations sometimes has a funny effect of only the textMorph of transcript partially overlapping the top Window * From a newbie perspective, need to keep a list of methods break point cannot be put in, which are polling code.. Will need to get more precise and come back on them with fixes as possible. I will revert to the older breakpointing of using self halt inserted at top/ line I need with the "Toggle breakpoint" and check also.. Will dig in deeper and come back.