Finder Bring All To Front doesn't apply

Questions & Suggestions
1

Just wondering if anyone else can confirm this:

I have set up a KM workflow:

when Finder Activates:

Select "Bring All to Front" in the Menu "Window" in Finder

The idea being that if I have finder windows obscured by another application on a display, I click any available exposed desktop background, and it should bring all the finder windows to the front.

But it doesn't work for Finder windows obscured by the app you're switching out of (Even the KM Editor).

So, lets say I have a Safari window, with a Finder window behind it, and a Mail window with a Finder window behind it, if I click the empty desktop while Safari is the foreground application, the finder window behind Mail will be revealed, but not the one behind Safari, and vice versa.

If I just click Finder in the dock, all the windows come to the front, but what's going on to insulate the app you're leaving from Finder's window stack alteration?

If I manually select Window > Bring All to Front when Finder has become the foreground app after clicking the desktop, all the windows are brought to the front, but...

...If I put a second instance of the Bring All to Front macro in the KM script, which should be doing the same thing as selecting it manually, it doesn't work.

Am I missing something here?

edit Strangely, John Siracusa's Front & Center app is able to effect the behaviour correctly, but it's not able to be restricted to just one app (Finder), so presumbly the outcome is achievable somehow?

edit again The behaviour does work when selecting any Finder window as the way to switch to Finder - all finder windows are brought to the front. So is there something different about the Activation mode of clicking the Desktop background, Vs. clicking a Finder window that is tripping it up? I Note in Front & Center there's a setting to choose activation on selecting a window, vs any activation. Is there a granularity there that KM isn't exposing?

2

I tried replicating your macro without being able to see your macro, but I was unable. I think part of my problem was that I have Stage Manager enabled, and you probably don't. I recommend that you show your macro, and you should probably indicate whether you have Stage Manager disabled or not. I think it's enabled by default, since I don't remember enabling it myself.

3

I don't use Stage Manager. Here's the Macro:

image
image815×432 42.3 KB

4

I can't replicate the issue, though I say that from an older Mac and OS. Which makes me think that maybe inserting a Pause before having Keyboard Maestro select the menu item may be necessary. Just 0.2 seconds or so.

5

Yes, I've tried using pauses, but it doesn't seem to change things - the pause delays the outcome, but it just does the same thing a bit later.

Edit: I should add, this is on Ventura.

6

Have you tried using the dedicated KM action instead?

image
image1042×646 55.2 KB

7

Ahh fantastic - always more to learn. That solves it :slight_smile:

Still baffled as to why the behaviour is the way it is when using the finder menu option, but for now, KM becomes more indispensable.

8

I may have been right. Your lack of having Stage Manager was probably why I couldn't replicate your problem.

9

My Mac/OS pre-date Stage Manager and I also couldn't replicate the problem.

10

The Finder sometimes behaves a bit oddly. It may be as simple as that.

The Finder does a lot of things asynchronously when it gets around to it, and that can cause timing issues - it might simply be that the Finder hasn't actualized the windows at the time, or thinks it is still in the background, so maybe a short pause would do the trick?

11

I haven't found a timing solution to it - it appears Finder (or the window manager) teats the application you've just left by clicking the desktop as immune to giving up its foremost position in the window stack.

I'm almost wondering if this is someone's idea of a "helpful" behaviour - an assumption that if you're in an app and you click the desktop, your view of the app you were in should be preserved.

What's most strange to me is that if you run the command a second time in the script, even with time delays, it still doesn't alter the window stack. You have to manually interact with the menubar (or some other Finder element) to get the Bring All to Front command to change the stacking order of the application you left.

12

That's possibly it -- drag-and-dropping a file from the Desktop into an app window would be a real pain if as soon as you clicked on the Desktop all your Finder windows popped and covered the app window...

Finder isn't alone in this -- clicking a non-active app's window will bring only that window to the front, with the previous app's windows behind it. Doing that with the Desktop just looks a bit weird since it's a window that isn't a window -- it can't come to the front so you get Finder activation without any change in window stacking.

13

Yet all the windows of an app (including Finder) come forward if the user uses Command-Tab to switch apps instead of clicking on the window of a background app. Likewise, the same is true if the user Option-Clicks a window on a background app (which brings the background app to the front and hides the previous app). Both of those seem to match the idea that

14

Yeah but what's strange is that by default, clicking from an app to the desktop activates finder, but doesn't change the window stack. Then, manually selecting Window > Bring All to Front brings all the finder windows to the front, including the ones that were behind the app you just left.

Yet when KM fires off the very same menu command after you click the desktop, the app you just left does not have the finder windows behind it brought to the front.

So there is something different happening between KM issuing that command, and the user issuing that command by physically accessing the menubar, that causes a different outcome.

A further test of it would probably be to create a native macOS shortcut for the menu via accessibility settings, and see which behaviour comes from firing that off after clicking the desktop. Then firing off the keyboard shortcut via KM.

I have a hunch that physically interacting with the menubar adds a level of progress away from the app you switched out of - takes you one step further into Finder conceptually, and that is what releases the insulation of the previous app from the window stack change.

15

It looks like an activation problem with Finder when clicking on the Desktop. Selecting the Finder menu bar item at that point fully activates Finder, which is why the manual approach works. You can do the same in your KM macro:

image

...or you can explicitly activate Finder:

image

...which, with "All windows" ticked, brings all the windows to the front anyway.

1 Like