I just ran into a case where all morphs became unresponsive, and clicking anywhere only gave me the World Menu. After some investigation, it turned out all the World submorphs had been locked, and I could "unfreeze" them with the following (from a new Workspace): World submorphsDo: [ :aMorph | aMorph unlock ] What triggered it? Well, the image had become unresponsive, so I clicked the close buttons a couple of times (before trying good ol' cmd-dot, which brought up a debugger on the old UI process and let me continue). The close dialog is modal, normally that's no problem, since the modal morph locks all other morphs, no two can be opened at the same time (unless you somehow let that modal morph open another), but the close triggered by the system window's close button is special, since it is triggered outside the control of the World. The bug is rare in occurrence, yet easy to trigger; press the window close button twice, cancel one of the close dialogs, all windows that were open will remain locked and seem unresponsive. It might be smart to rethink the whole modality concept to make the code more robust/coherent, but for now an extra check for this single case in PasteUpMorph >> windowEvent: (for instance, using a morph property) should do the trick, I'll submit a slice shortly. Cheers, Henry