Page MenuHome

On OS X, when switching from another app to Blender via Mission Control, it doesn't work.
Closed, ResolvedPublic


System Information
Operating system: OS X 10.9.5
Graphics card: NVIDIA GeForce GT 650M 1024 MB

Blender Version
Broken: I have seen it since 2.69.0 to 2.72a (haven't tested it on any version prior 2.69.0)

Short description of error

On OS X, when switching from another app to Blender via Mission Control (the OS X feature that spreads out in your screen every window/app you have open) it doesn't switch. Blender kind of hides in the back, you need to repeat the process and then it works fine. Here is a dropbox link to a quick video for easier understanding, sorry if I can't explain myself with words:


Exact steps for others to reproduce the error
With Blender opened, switch to another app, then via Mission Control select Blender. It will hide itself.

Event Timeline

Claudio D. (claudio) raised the priority of this task from to 90.
Claudio D. (claudio) updated the task description. (Show Details)
Claudio D. (claudio) edited a custom field.

I can't recreate that here on OS X 10.10 AMD Radeon HD 6770M 512 MB.

Forgot to mention this is a retina display. I remember not so long ago there was a weird error when adding nodes (the nodes didn't add where the cursor was) that only happened on a retina display. Maybe this also happens only on a retina display? Also, this only happens with Blender.

Thanks for your help.

Cannot reproduce here on MacPro with AMD gpu atm.
Can only guess its something with retina and backbuffer
preventing Blender to be frontmost app on the first call.

Can somebody with NV try ?


Sergey Sharybin (sergey) lowered the priority of this task from 90 to Normal.Oct 21 2014, 9:34 AM

@Thomas Dinges (dingto), you've got mac for as long as i concerned.

Cannot confirm this either, I open Blender, go to Safari, then via Mission Control back to Blender, opens fine.

I can actually reproduce this behavior and remember it bothering me in earlier versions of Blender...

I'm also on a 15" Retina MacBook Pro.
OS: OS X 10.10
Graphics: GeForce GT 750M

I tried to debug this issue on the current master branch. The event flow is exactly the same as if you would use command+tab (windowDidBecomeKey is received when switching to Blender and windowDidResignKey when switching to another application). It appears the window just gets ordered to the background. Repeating the Mission Control action orders the window on top (no additional windowDidBecomeKey is received).

Now I stumbled onto a weird solution for my system: I added a windowDidBecomeMain method to the CocoaWindowDelegate interface and this glitch doesn't appear anymore. I have no idea why, but it works for me.

FYI: the windowDidBecomeMain is received before windowDidBecomeKey message.

If you know how to compile Blender yourself I can provide you a patch so you can see if this works on your system, too.

Must look at this first.
Normally we prepend [m_window makeKeyAndOrderFront:nil]; just fine.
Looks as something with the retina backbuffer is fishy.
I remeber i can simulate retina on my nin-retina gfx too.
Must check this over.


I had a look at it again and you can forget my patch. It has nothing to do with the problem, sorry. I narrowed it down why it worked for me to a break point I had set which just prints the eventType in GHOST_SystemCocoa::handleWindowEvent without pausing execution... Disabling the break point leads to the old behavior. Replacing the break point with a printf statement has no effect on the glitch.

BTW: [m_window makeKeyAndOrderFront:nil] is only called once in the constructor

Joel, can you please help me ?
Simulating retina res, i can still not reproduce this issue.

Try add prints or NSLOG to check if the windowDidBecomeKey
reponds when switching. If so please try add an: [[NSApp keyWindow] orderFront:nil];
after: systemCocoa->handleWindowEvent(GHOST_kEventWindowActivate, associatedWindow);

Your patch would not harm afaik, but i would rather understand the rootproblem first.


[[NSApp keyWindow] orderFront:nil]; after systemCocoa->handleWindowEvent(GHOST_kEventWindowActivate, associatedWindow); didn't help.

As I said earlier windowDidBecomeKey is received just when clicking on the window in Mission Control. Then the window goes back to its previous order. Repeating this orders the window on top. No additional windowDidBecomeKey is received as if the window was already key. It appears the window is actually key even though other windows are on top (mouse overs are received). No intermittent windowDidResignKey is received.

I also tried low resolution mode via the checkbox in the info panel and the glitch is still reproduceable.

If you only use Mission Control to switch between windows this glitch does not appear. Only when you combine it with command+tab.

I could now reproduce this behavoiur by switching to another app with cmd-tab then with mission-control trying to go back.
Not sure if this is a system bug or if we can workaround this, anyway i beliece this is a cornercase in usage.

Tetsing some things ....


K, 'am 1 step further:

It has todo with mssioncontrol settings, if you disable the highestmost option ( duuno the exact engl. naming )
it goes away:

Now must lookup, if we can influence this from inside the app, but seems a known bug:


I have the same options checked as you do but the glitch still appears...

Okay, i think i have a solution, try this patch pls:

diff --git a/intern/ghost/intern/ b/intern/ghost/intern/
index 9e47ea1..a8bab88 100644
--- a/intern/ghost/intern/
+++ b/intern/ghost/intern/
@@ -86,6 +86,7 @@ enum {
 - (void)windowDidBecomeKey:(NSNotification *)notification
        systemCocoa->handleWindowEvent(GHOST_kEventWindowActivate, associatedWindow);
+       [[NSRunningApplication currentApplication] activateWithOptions:(NSApplicationActivateAllWindows | NSApplicationActivateIgnoringOtherApps)];
 - (void)windowDidResignKey:(NSNotification *)notification

Atm. checking if this has any unwanted impact.


patch was truncated -> corrected

This works. :)
But it doesn't really go to the root of this problem. Now the window disappears in the background and immediately comes to the top again which looks weird. Also if you have multiple Blender windows and you're in another App and click on one Blender window all Blender windows are brought to the top.

But I agree the issue might be that Blender doesn't get activated but the window still becomes key.

Also I found these:

Okay, try this, i think this is the right appoach:

diff --git a/intern/ghost/intern/ b/intern/ghost/intern/
index 9e47ea1..283f7a3 100644
--- a/intern/ghost/intern/
+++ b/intern/ghost/intern/
@@ -66,6 +66,7 @@ enum {
 - (void)setSystemAndWindowCocoa:(GHOST_SystemCocoa *)sysCocoa windowCocoa:(GHOST_WindowCocoa *)winCocoa;
+- (void)windowDidBecomeMain:(NSNotification *)notification;
 - (void)windowDidBecomeKey:(NSNotification *)notification;
 - (void)windowDidResignKey:(NSNotification *)notification;
 - (void)windowDidExpose:(NSNotification *)notification;
@@ -82,7 +83,10 @@ enum {
        systemCocoa = sysCocoa;
        associatedWindow = winCocoa;
+- (void)windowDidBecomeMain:(NSNotification *)notification
+       [[NSRunningApplication currentApplication] activateWithOptions:(NSApplicationActivateAllWindows | NSApplicationActivateIgnoringOtherApps)];
 - (void)windowDidBecomeKey:(NSNotification *)notification
        systemCocoa->handleWindowEvent(GHOST_kEventWindowActivate, associatedWindow);

This still has the problem that it orders ALL Blender windows on top.

What works for me is this:
[(NSWindow*)associatedWindow->getOSWindow() orderFrontRegardless];

in windowDidBecomeKey

Interestingly [NSApp keyWindow] is nil in windowDidBecomeKey which looks to me like a bug...

diff --git a/intern/ghost/intern/ b/intern/ghost/intern/
index 9e47ea1..6514c98 100644
--- a/intern/ghost/intern/
+++ b/intern/ghost/intern/
@@ -86,6 +86,9 @@ enum {
 - (void)windowDidBecomeKey:(NSNotification *)notification
        systemCocoa->handleWindowEvent(GHOST_kEventWindowActivate, associatedWindow);
+       // work around for
+       [(NSWindow*)associatedWindow->getOSWindow() orderFrontRegardless];
 - (void)windowDidResignKey:(NSNotification *)notification

Do u use the "seperate spaces" option ?


I adjusted my settings so they match yours. So I have "Monitore verwenden verschiedene Spaces" deactivated. Why do you ask?

Edit: tested with the option activated: works, too.

Just to assure we are talking about same prelimnaries.
Your tweak looks best atm., i compared with document based apps and the behaviour looks same ( textedit with several docs open ).

So perhaps we can use you diff after checking once over (?).


Well there's still a small flicker sometimes as if the window gets put to the back in one frame and then to the top. It isn't perfect but basically it works...

Didn't notice, we should get rid of any flicker i think.


I recorded a video of the flicker. It's just one frame. Also it doesn't always appear.

I just did an update on OS X to 10.10 version. I didn't do a clean installation, I kept every program and settings, and the error seems to be gone. I tried 2.71, 2.72, 2.72a, 2.72b and now I don't get the error. I don't know what this might tell you about the error.

Ok so I don't know what is happening but as soon as I sent the last message I started to get the error again on 2.72b.

Please note the exact steps to reproduce this problem are:

  1. Press Command+Tab to switch to any other application
  2. Open Mission Control and click on the Blender window

The Blender window should animate into position and before it finally arrives it will be ordered back into its old position.

Sorry, was away for some hours.
I must investigate this still a bit, it is not such imminent issue i think,
We should aim a clean solution for 2.73 though.