Possible Bug: Manipulate a Window Interacts Differently (And Unreliably) With Different Applications

[cdthomer]

Howdy folks. I am posting an interesting phenomenon I am experiencing ever since the latest Big Sur update. Tagging @peternlewis since we had discussed this in another topic. I have included a video recording of what I am talking about to explain it further.

Basically, manipulate a window no longer works reliably. Sometimes it will reposition the window correctly, and sometimes it simply won't. There doesn't appear to be a rhyme or reason as to when it works or not. Stranger still, now some applications even animate moving the window around, while other apps do not. They never did this before. Finder and TextEdit seem especially prone to this issue.

Peter suggested it could be interference from other apps that also control window positioning. I have Better Touch Tool and Rectangle installed, so I temporarily disabled them, but the issue is still present.

I first noticed it after the latest Big Sur update (now running 11.5.2), however I cannot guarantee that it was that precise moment when the issue started to arise. I'm stumped as to why it's happening, and even went so far as to uninstall and reinstall Keyboard Maestro, but that has not had a visible affect on the issue.

So if anybody has any ideas as to what might be causing the issue, I'm all ears!

Screen recording (hosted in my Dropbox account)

Sorry I wasn't able to embed the screen recording in the post...when I converted it to GIF format it was still too large so I had to put it in Dropbox.

EDIT: Maybe my GIF isn't even working...but I gotta eat lunch so I'll try to fix it after

EDIT 2: I can't seem to get the screen recording and/or GIF image to work properly so they may not show up using that Dropbox link. Maybe somebody has a suggestion in that regard...

[hello]

Unrelated: GIFs have to be <1.5 MB

[peternlewis]

Unfortunately, when it is something specific to your Mac, it is very hard to suggest what the issue might be.

Things to try include:

• Safe Boot.
• Create a fresh new account, and see if it happens there.
• Disable all Launch Agents & Daemons and Login Items and see if it still happens.
• Give up and install a fresh OS and start again from scratch.

[cdthomer]

I'm posting this just to share an update with anybody who comes across this post nowadays.

I never have found a solution to this issue but I found a workaround. Basically I use a global variable along with a repeat action to ensure the window is properly positioned. Since global variables are unique to each machine, I have it set to 1 on my iMac and 5 on my MacBook since it is the one that has the problems.

Screenshots (click to expand/collapse)

[cdthomer]

Update: I posted a macro here that uses an AppleScript to ensure proper positioning in case folks continue to run into this issue in the future.

KMF: Repeatedly Position a Window (For Machines That Suffer From the Window Positioning Bug) - Macro Library - Keyboard Maestro Discourse

-Chris

[BernSh]

Responding to:

@peternlewis

Yes, sadly the Accessibility API has a nasty habit of simply ignoring part or all the request to change the window. Apparently there are apps that can make this worse or better by turning on or off an undocumented accessibility parameter.

As it is, Keyboard Maestro already executes the Accessibility requests multiple times when making the changes.

One thing to try is to simply add a Repeat action around the Manipulate a Window action (and maybe a small Pause as well) and repeat the action 3 times and see if that improves reliability.

Thank you. I will follow up if it does not work.

Looking at @cdthomer's idea of checking and repeating until achieved. While there is a built-in mouse position display, there's no window position equivalent. I've seen window position gathered and used with scripting but nothing built-in. With a window position display or at least a window position condition, a run until the position is achieved could be made through that opens an endless loop possibility unless the number of repeats is limited and reliably gathering window positioning on multiple monitors and devices seems problematic. Then there's what Apple provides (or doesn't) or does and changes.

Probably too little value in compensating for a bug.

[ccstone]

Look at these:

• %FrontWindowFrame% token and the related window tokens.

[BernSh]

Correction:
@ccstone kindly pointed out that there are various window tokens that return window location parameters. That helps my understanding. Thanks Chris!

All that’s missing are built-in window condition parameters that reference window locations in addition to currently existing window names condition settings.

[ccstone]

@BernSh

All that’s missing are built-in window condition parameters that reference window locations in addition to currently existing window names condition settings.

Huh? Please elucidate...

[BernSh]

I'm unclear about the terms and using them badly and giving incomplete information.

The If Then Else action has conditions for window titles, existence, and full 'screen-ness' :

but not for specific window locations. If a location could be specified as an IF condition like if the focused or any window is in or not in the upper left quarter quadrant of the screen THEN move it there or not.

Does this make sense?

[ccstone]

@BernSh

Does this make sense?

Ah, now I get it.

You just need to use a calculation condition and window functions, or you can use the window text-tokens – break them up – and use them in calculations.

Here's a quick example:

Front Wndow Conditons v1.00.kmmacros (8.4 KB)

[BernSh]

This doesn't work to move a window to the top left if it isn't there.

I'm guessing I'm missing the first action and don't know how to say if true, do nothing.

Also, you noted, 'Don't forget the functions which are needed in calculations.' I don't know how to evaluate and use that. What functions and which calculations?

Tone note:
I'm writing succinctly, which doesn't express my appreciation of your generosity. I don't want to overlook that .

[cdthomer]

@ccstone Chris,

Thanks for showing those calculations; I wasn’t aware of the ability to run multiple calculations in a single field.

@BernSh based on Chris’ information, I put together this example macro that will repeat moving the front window until it’s bounds match the integers the user puts in the variables. This essentially works the same way as my AppleScript subroutine, but with native Keyboard Maestro actions. One caveat, as it’s built right now it only works on the front window and front application. I will see if I can come up with something to work on background windows and applications as well and then test in the coming weeks to see if it works either faster or more reliably and update this post.

P.S.: I use global variables prepended with debug__ for testing, and usually include an action to delete them at the end of my macros. I forgot to do that with this sample, so you will need to delete them if you don’t want them to persist in your Keyboard Maestro database. My apologies for that oversight.

Scratchpad.kmmacros (7.7 KB)

Macro Screenshot (click to expand/collapse)

[BernSh]

Nice!

Yours with these positions:

Puts a window in the upper left quadrant w/o the AppleScript first action on my MBP. Thank you for extending the idea w/o scripting and with a calculation. It's nice for a simple way to add custom values for positioning.

Chris' like this:

Works and IDK what moving/remove image margins on the system clipboard has to do with window placement.

Both allow using the preformatted common locations (or custom) within the Move and Resize popup menu, which covers most of my use cases:

And Peter's repeat suggestion rounds out enough ways to get this done!

What are your use cases which need to move background windows?

And finally, thank you for initiating this thread.

[cdthomer]

@BernSh

What are your use cases which need to move background windows?

Typically, for my larger workflows, I have all of my “position/move/resize actions” as part of a separate macro that I call via an “Execute a macro” action. Note that I do not call that via the “Execute a subroutine” action, because that way does not allow me to run them asynchronously like the “Execute a macro” action does.

So, by placing them in a separate macro, calling it via an asynchronous “Execute a macro” action, I can have all of the resizing, positioning etc. done in the background, while the rest of the calling macro does other things.

For a real example, consider my “open my work apps” macro:

[details=“As part of it’s larger workflow, it has this action (click to expand/collapse)"]

[/details]

[details=“That action, in turn, calls this macro... (click to expand/collapse)"]

[/details]

[details=“...which in turn calls these... (click to expand/collapse)"]

[/details]

[details=“...each one of those in turn performing these actions (click to expand/collapse)"]

[/details]

It might seem complex, and perhaps it is too complex for some, or for some workflows. But this helps me to break things down into tiny little chunks which helps me with debugging, and then modifying macros later on. Instead of having to debug or modify one, ENORMOUS macro, I can work on a tiny little “subroutine” (though they are not set up as subroutines because of the aforementioned asynchronous feature) which is much easier to me.

-Chris