Behavior change in NSRunningApplication's activateWithOptions starting with Big Sur

Question

Created Dec ’20

Replies 5

Boosts 0

Participants 2

My application uses the keyboard to give focus to particular windows rather than clicking with the mouse. (I have a hand tremor that causes my mouse clicks to frequently miss the intended target.)

The application:

uses the AppKit "Accessibility for macOS" API to select a window. It calls the AXUIElementSetAttributeValue function to set the attribute NSAccessibilityMainAttribute to make a window "main" and then
calls NSRunningApplication's method activateWithOptions: passing only NSApplicationActivateIgnoringOtherApps to activate the app associated with that window.

Based on the documentation for the activateWithOptions: method, which 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.

and the fact that I am not passing NSApplicationActivateAllWindows, I expect only the main window (which is also the key window) to move forward.

However, all the windows of the app being activated are brought forward, obscuring windows from other apps.

For example, if I am running two apps AppX and AppY with

windows X1 and Y1 covering the left half of the screen and
windows X2 and Y2 covering the right half of the screen

If I start with windows X1 and X2 visible, then make window Y2 "main" and activate app AppY with activateWithOptions:, I would expect to be able to see windows X1 and Y2 with window Y2 receiving keyboard input.

That is the behavior I saw prior to Big Sur.

Since upgrading to Big Sur, however, when AppY is activated, both window Y1 and Y2 are brought forward.

Boost

Answer 1

nielsmouthaan OP

Dec ’20

I am experiencing the same issue.

0

Answer 2

colin.fraizer OP

Dec ’20

Anyone have suggestions on ways to work around this problem until a fix is available? Using an app like "Witch", I can raise only particular windows from an app (without raising them all), so clearly this is *possible*. What could I be doing instead?

0

Answer 3

colin.fraizer OP

Dec ’20

Anyone have experience with Apple's track record on fixing such bugs? So far, I've received no response to my Feedback entry and no acknowledgment from anyone (except the kind notice from @nielsmouthaan that he is also experiencing this issue). I've also verified with others that they see the same change in behavior.

1

Answer 4

nielsmouthaan OP

Dec ’20

Unfortunately my experience hasn't been that great with reporting feedback. I have another pending issue that clearly is a bug, also confirmed by others, that still hasn't been resolved. It would be better to find a workaround but I'm also failing in finding one...

0

Answer 5

nielsmouthaan OP

Dec ’20

I've just managed to make my app work correctly again using the following code. It uses deprecated functions (as of 10.9) so I don't expect those functions to disappear soon. Not ideal, but at least it does not result in a weird user experience.

Code Block - (OSStatus)makeApplicationFront:(NSRunningApplication*)application
{
    if(!application || application.processIdentifier == -1) {
        return procNotFound; // Previous front most application is nil or does not have a process identifier.
    }
    ProcessSerialNumber process;
    OSStatus error = GetProcessForPID(application.processIdentifier, &process); // Deprecated, but replacement (NSRunningApplication:activateWithOptions:] does not work properly on Big Sur.
    if(error) {
        return error; // Process could not be obtained. Evaluate error (e.g. using osstatus.com) to understand why.
    }
    return SetFrontProcessWithOptions(&process, kSetFrontProcessFrontWindowOnly); // Deprecated, but replacement (NSRunningApplication:activateWithOptions:] does not work properly on Big Sur.
}

Hope it also helps you.

1