Change in behavior of `Window.focus()`—it now raises all windows of the app.

[cfraizer]

• Version: 2.6.5 (87)
• macOS: 11.0.1

Say I have two apps and four windows:

• Emacs with 2 side-by-side windows, one covering the left half of my screen (call it E1), the other covering the right half of my screen (E2).
• iTerm2 with 2 side-by-side windows, one covering the left half of my screen (call it T1), the other covering the right half of my screen (T2).

Prior to upgrading to Big Sur, I could use Phoenix to Window.focus() the window T2 and then Window.focus() the window E1 and be able to see E1 and T2 at the same time.

Now, when I Window.focus() window E1, it raises both E1 and E2 (obscuring T2). If I then Window.focus() T2, it raises both T1 and T2, obscuring E1.

Obviously, this isn't your fault, but some behavior change in OS or framework code. I'm not much of a Cocoa developer, but I'd be happy to try to help if given some advice.

[kasper]

@cfraizer Thanks for the report! I just updated to Big Sur, and while most things seem to work as expected, I need to do a brief pass to check what might have changed. It might be that the first conditional here (https://github.com/kasper/phoenix/blob/master/Phoenix/PHWindow.m#L439) fails and it defaults to focusing the whole app instead.

[cfraizer]

Your intuition was spot on. That is exactly what is happening. [Laugh at my idiocy: I didn't know how to run an actual debugger against it, so I just added some NSLog statements. Nevertheless, I am certain that the PHWindow focus() method is failing the call to setAttribute:withValue: and proceeding on to call [self.app focus].

[kasper]

@cfraizer Does this happen by the way across all apps or just individual ones?

[kasper]

Thanks for checking by the way! For the debugger, just click on the line number in Xcode, it should add a breakpoint to the line and then run the app again. The debugger will then stop at that line.

[cfraizer]

@kasper It seems to happen across a variety of apps, but I'll try more today and update this ticket.

[kasper]

Thanks! It might be a bug in Big Sur as well.

[cfraizer]

Confirmed that the behavior is the same using windows from Chrome and Apple's Messages app. Whereas before Window.focus() would raise (and focus) only the target window, now it raises all the windows of the app of the targeted window (and focuses the targeted window—as it should).

[kasper]

After some debugging, this feels to me like a bug in Big Sur. The behaviour has just changed without any reference.

[cfraizer]

Yeah, this behavior is just completely wrong, per their documentation. The documentation for NSRunningApplication's activateWithOptions: method says:

By default, activation brings only the main and key windows forward. If you specify NSApplicationActivateAllWindows, all of the application's windows are brought forward.

But that is not what it does (anymore). Do you know the best way to bring this to Apple's attention so it can be fixed?

[kasper]

@cfraizer Submitting a bug report to Apple at https://developer.apple.com/bug-reporting/.

[cfraizer]

Cool. I did that this morning. (Not that they ever seem to look at those.)

[kasper]

@cfraizer Thanks! Yeah, unfortunately. I will also try to file a duplicate so it gets more traction. 😄

[cfraizer]

Hi, @kasper,

Thanks to some helpful folks, I found a non-ideal work-around for this issue:

I changed PHApp.m's focus method so that it calls SetFrontProcessWithOptions() instead of NSRunningApplication's activateWithOptions.

I realize that SetFrontProcessWithOptions() is a deprecated API, but it does have the nice property that it still works. :-)

I tested the relevant functionality and it seems to work. If you're at all interested, I can create a pull request and submit it for your review. [When it comes to Mac development, I'm a novice, but I'd be thrilled to receive constructive feedback.]

I wonder if we could make it a configuration option until Apple fixes the new API? [Of course, if you don't want to be bothered, I'm happy to just run my own locally-built instance of Phoenix.]

[kasper]

@cfraizer Hi!

Interesting! Have you tested the APIs on Big Sur 11.1? I’d be more than happy to have this as a workaround for Big Sur if you make it conditional for this OS version. Out of curiosity, have you received any response for the bug report?

[cfraizer]

I've only tested it in on Big Sur 11.1. Info about my MBP.

I just submitted a pull request for your review.

I checked FeedbackAssistant again just now. No response from Apple. :-(

[kasper]

@cfraizer Thanks! I’ve commented on the PR, let’s see how long does it take for Apple to fix this one.

[kasper]

The workaround for the macOS bug has been merged to master and will be released in 2.6.6.

[cfraizer]

@kasper Are there other bugs or small features on which you'd like help?

[kasper]

@cfraizer Everything is tracked in the issues, you can see if you spot anything interesting. 🙂