Many, many thanks, Nickkk, for your great suggestion! In the meantime I discovered that the misbehavior disappears in macOS 12 Monterey and macOS 11 Big Sur, that I happen to have installed on two other computers. I don’t know about macOS 13 or 14, that I don’t have already installed anymore. In any case, I finally found the — very unexpected — cause of the bug. I applied Nickkk’s idea. It took me quite a while, because the app is very big and I wanted to reduce it in relatively small steps, so as not to miss the cause of the misbehavior. A few times of course I had to come back to a previous reduction, and so on. Finally I found the part of the code that produces the bug. Here is a description of what is involved. • I wanted to observe NSApp’s property “effectiveAppearance” in order to modify the content of certain windows whenever effectiveAppearance changes, • so in my document class’s init method I added the statement [NSApp addObserver:self forKeyPath:@"effectiveAppearance" options:0 context:NULL]; • and consequently declared and defined the method observeValueForKeyPath:ofObject:change:context:. • Finally, at some point in my reducing routine, I deleted all this observing stuff, though it didn’t seem relevant. But then the bug disppeared! Wow! Well too bad if the interface doesn’t change as I’d want it to when the “effective appearance” changes…

Great idea, Nickkk! I’ll try to do just what you suggest!

Well, I found pretty quickly an incongruous bringToFront: in my drawRect: code. Am I ashamed! I had put it there a long time ago, without thinking a second, in order to “solve” a problem that appeared when a document was being opened, that necessitated an alert concerning an error in the file. I had completely forgotten this, and my pseudo-solution came back on me with a vengeance. Thanks again!

Thank you for your reply! I’m using AppKit. This is a big program, written in Objective-C. Yes, indeed the calculations are made in a background operation queue. The code that updates the custom view in the background window is just a simple setNeedsDisplay: sent to that view, in an operation added to the main operation queue. However, what you wrote made me think that maybe, surreptitiously, it’s my drawRect: method that, somewhere, somehow, brings the window to the foreground. My drawRect: method is v e r y complex… I’ll examine it thoroughly and will post a sequel to my reply in a couple of days. Thank you very much for your thoughts!