Weird Issue Controlling Safari Windows

Questions & Suggestions
1

Screenshot 2023-11-16 at 09.08.28
Screenshot 2023-11-16 at 09.08.28870×1020 110 KB

I use this very simple macro to "maximize" a window (not full screen, not unminimize—I mean to expand a window so that it fills the desktop space on the main screen). This generally works great . . . except in Safari. I'm on Safari Version 17.1 (19616.2.9.11.7), on Sonoma 14.1.1, though the problem started sometime before.

What I get instead varies. Sometimes the Safari window will expand a bit and move all the way to the right. Or to the left. Or just expand a bit more. I cannot reproduce the problem with any other application. I've looked for possible conflicts that might have to do with Safari in particular and can't think of anything.

Has anyone else seen this? Thoughts? Or, is there an alternate, maybe more reliable way to get the window behaviour I want?

2

If I had a problem like this, what I would immediately do to debug it is add a second action before or after this action that displays those four function values, so that I can detect if the SCREENVISIBLE() function is returning the right data or not. That would give us a big clue depending on whether the data it returns is accurate or not.

3

That's interesting and helpful, thanks!

So what I've done is added a Display Text action before and after the Move & Resize action, to display this:

%ScreenVisible%Main%
%WindowSize%1%
%WindowPosition%1%

Then I'm executing the macro and comparing what's displayed. And without getting into the nitty-gritty of the values, basically it seems to share what's expected. i.e. it shows 4 values (Left, Top, Width, Height) for ScreenVisible(Main), and those look correct and never change. Then for WindowSize and WindowPosition it seems to be showing correct information before and after regardless of what the macro does to the Safari window—it's just that the Safari window isn't doing what I expect it to (and what windows from every other app do).

4

Well, that helps narrow down the cause. A little bit. Apparently, I infer, the problem is with Safari not honouring your resize request.

I'm pondering it. When you say "it expands a bit" do you mean it fully expands vertically but not horizontally? Since we can't see your results, we have to ask questions like this. You said "a bit" but I don't know what "a bit" means to you.

Okay! I'm able to replicate your problem! Now I can really investigate. I've noticed a pattern. When I perform the resize action three times in a row, (with a pause inserted) it always works. So if you are just looking for a quick fix, do that. If you're more interested in a perfect solution, that may take time.

I've tried it with dozens of apps, in various settings. Safari isn't the only app. The KM Editor is another such app. It always has the same behaviour as Safari in dozens of my tests. So it's probably easier to address because now we don't need a separate app (i.e., Safari) to test with. I cannot blame Safari if the same problem occurs with the KM Editor. That leaves two culprits, the KM Engine or the macOS API which is receiving the requests from the KM Engine. In my experience, when it's a choice between KM or macOS, it's usually macOS that contains the bug. I'm not sure if it's directly related, but I found a thread on a similar subject here:

I rarely tag @peternlewis because I hate to bother him, (and I'm usually wrong when I ask him a question) but I think we can ask him the following: When using the KM Editor, and "Trying" the following action, why does it take three "Tries" before the KM Editor window becomes full screen? (My versions of Safari and macOS are the same as the original poster's.)

image

5

Thank you for your diligent attention to this! It's interesting and reassuring that you can replicate it.

You're right, there's lots of specificity I haven't provided. The intent of my original post was not, "Please help me systematically debug this issue," but rather to see whether it would evoke any, "Oh, THAT? Yeah, it's been there for a year. The fix is . . ." replies. I hope I wasn't misleading in that regard.

A couple of additional facts:

  • I still haven't gotten any app besides Safari to show it, and that includes testing on the KM app.
  • Yes: I find that if I keep invoking the macro, it eventually gets the window to full size. I hadn't noticed that the magic number was 3! But I find that plausible.
  • Very interesting: BetterTouchTool does the same resizing function, and has no issues with Safari in my testing. This (and more importantly your replication) gives me some reassurance that it's a KM issue and not funky interference from something else about my system. (It also gives me a solution . . .)
  • It's not just the maximizing that fails. I have a few other resizing macros that I use very often. They always work for me, except with Safari. I didn't mention this in my original post, because it only became clear to me in testing since. It's hard for me to summarize exactly what happens for each resize request, because it seems to vary.
6

Anything that's unexpected is a clue. That statement was unexpected. Therefore it is a clue.

7

I get the same odd behaviour in Safari in Ventura. I will look in to ti further. It's nice to have a repeatable case.

1 Like
8

For the record, I have been experiencing a similar problem in various apps since upgrading to KM11. While the problem is not as neatly reproducible as this one (which I can reproduce as well), it occurs most often in Microsoft Word. After Word has been running for a while (TBD), it starts acting up when it comes to moving and resizing windows with KM macros. As is the case here, it takes several successive triggers of the same macro to eventually get the window to the desired position and size. The same thing also happens in Safari after Safari has been running for a while. And I've seen this problem at least once in Nisus Writer Pro as well.

Interestingly, I do remember seeing this problem ONCE in a version of KM prior to KM11. But it was an one-off and I chalked it up to some kind of glitch. Now I realize it was a rare occurrence of a long-standing problem, which unfortunately has come to the fore with KM11. (I started having the problem with early betas of KM11 in Ventura. Reverting to KM10 would eliminate it.)

I have been in touch with Peter about this. It's good that he now has a reproducible scenario! Hopefully it's the same underlying cause (probably a bug in macOS's Accessibility API) and he can figure out something to do about it, either by undoing whatever has changed between KM10 and KM11 or by finding some other kind of workaround.

In the meantime, for MY problem, I have found that replacing the single Move and Resize action with two SEPARATE actions, Move first and then Resize, with a pause of 0.5 s between the two, helps quite a bit. It does not COMPLETELY fix the problem (once it start occurring, after the window's parent app has been running for a while), but it moves the window to the right horizontal position and it resizes it to the right height and width after a single trigger. But the vertical position is still wrong (it stays at the very top of the screen), although ONLY when I try to move the window from my main display (with the menu bar) to one of my side displays (with no menu bar). In those cases, I have to trigger the macro a second time to get the window to move to the right vertical position. So it's better than having to trigger the macro 3 times every time, but it's not perfect either.

For the record, with your particular scenario (macro to maximize in Safari), the magic number is three times on my Mac too, with Sonoma 14.1, KM11.0.1 and Safari 17.1. (I have a 6K display.)

Sadly, my workaround with the split actions and the pause in between doesn't seem to work for your problem. The move works right, but the resize doesn't, no matter how long the pause is. Sorry!

9

Your message could be helpful to Peter. Of course, he can already duplicate the problem so I'm sure he's going to try to fix it, if it can be fixed. Sometimes the problem is with macOS API rather than the KM Engine, but sometimes he can implement a workaround to make a faulty API do the job correctly. I'm sure he's very busy with KM v11 issues, so give him a little time to work on this one.

10

Forgot to mention that there are other reports unreliable window manipulation on the forums, such as this one:

11

Can confirm that Peter seems to have found a workaround that fixes this particular reproducible problem for me in Safari:

I will try and confirm if it also fixes my own (less reproducible) problem in MS Word, Safari, Nisus Writer Pro, etc. It certainly looks like it will.

It's the eye candy (window animations)!

1 Like