Focus Macos

[Frederic Laureano]

The active window on my machine occasionally loses focus. The active app remains the same -- if I was in Chrome before, I'm still in Chrome now -- but the active window is no longer active. No window is active. This is frustrating; it happened while typing this question, and my keystrokes suddenly stopped registering.

This will sound silly and absurdly simple... I had the same problem with my laptop when I used the trackpad or built in keyboard. Had two separate laptops give similar experiences after being exposed to a bit of moisture (yes, I spilled on the keyboard).

There's also a script that can fetch the current Focus Mode (took it from Automators Discourse) and I've set it to save the focus mode to a variable whenever I wake my laptop. However it will not update manually if I happen to change the Focus Mode after I wake my computer.

Given that Focus Mode has a bunch of triggers built into every device I use (including the watch) and that this status sync to all of them, I figured it would be nice to have my Mac trigger a different setup macro (specific apps and settings) for each one of these Focus Modes.

Given that, look some of Rosemary Orchard's other posts -- in the Automator episode I mentioned she talked about syncing her Mac to her iOS devices via DataJar and/or Pushcut. So you could change Focus Mode on your phone and have your Mac react to that, with it also running macros etc.

I saw the script you refer to when I looked earlier, but it's set me thinking... If there's something you can check to find the current Focus Mode, presumably there's something that's changed when you change Focus Modes... If it's a file, that raises the possibility of a LaunchAgent using WatchPaths and triggering a response whenever that/those somethings change -- (a lot less resource intensive than the simple fix of your current Focus Mode checker once every second!).

Your recommendation to use Focus Modes as a trigger (in the Automation column) to run a shortcut that uses a remote trigger to activate Keyboard Maestro macros was exactly what I was looking for (though I am not the original poster of the question). Thank you!!

@RosemaryOrchard was using a change in focus to set a variable in Data Jar via a Shortcut automation. That data can then be referenced. You could write to an alternate location if required by your script of choice.

I believe focus modes sync across devices, so setting the focus mode on the Mac can set it on another device, which can trigger the shortcut automation. This can then be used to set your own indicator, which can be synced across devices and then queried on the Mac.

I was looking for this too and, after some digging, ended up writing the following in Javascript for Automation (JXA). It works with the JXA action in Shortcuts and should work in Keyboard Maestro, Alfred, Script Editor, Automator, osascript etc. The output is the name of the current focus mode, if any.

This is also useful for telling of your attempt at turning a focus mode on was successful or not. Check the defaults read after, and make sure that it says 1 and you know that something turned on at least.

Is there a way to turn off the "feature" where the clock in my menu bar becomes unreadable and black when the system goes into any of the "focus modes"? Just because I'm in "work" mode doesn't mean that I don't need to know the time... in fact, I need to know the time even more!

My theory is that there needed to be a way to know if Focus mode was enabled even if you hide the little icon, so hiding the clock was their way? Somehow the clock widget is related to the Focus setting since you can option-click the clock and it will toggle Focus mode on and off, making the clock visible again.

This has been driving me nuts for months. Thanks for the help. Apple folks, if you're listening, you should really make robgongora's setting the default, or at least make it easier to find how to control the clock-blocking feature. I'd have never intuited that turning on the icon was how to make the clock not do that.

Is it possible to make it so that the program can't do this? Instead it just bounces the dock icon? That's plenty annoying to get me to look at it. Nothing that it is saying is so important that it needs to be dealt with immediately!

AFAIK, focus on OS X is dictated by the application doing the stealing as well as the application which currently has focus (it is possible, for example, to program an "autocratic" UI application, such as a game).

That said, it may be practical in your situation to modify the focus-stealing app itself. Inside the app bundle is an Info.plist. Add the LSUIElement key and set it to 1. This will (should) remove all trace of UI or dock icon, though it will still be visible in activity monitor.

If you need to interact with this app's UI on a regular basis, this probably isn't practical. It might be just what you need, however, if you don't need to do more than launch it. Assuming it works with that app, that is.

I updated my BTT and noticed that you added BTT to Shortcuts, thank you. However, I think it would be great if I can set up a trigger on changing focus mode (ex. when I activate/deactivate focus "work" or any others). Though, it's possible to use automation on both iPhone and iPad that allows to set up running any shortcuts actions when any focus is on/off.

There are number of applications that I use that take several seconds( some take 10 seconds or more !), to open, or , since I have multiple displays, one I want to open in the left display while I am typing in the application in the right display, perhaps for reference.

I did some research online and found many instances of people asking this question, but not a single solution. I did discover a few people who said that macOS once upon a time did allow applications open without stealing focus, but that was pre-2011.

If the 1P application window is open, even if it's minimized, 1P will periodically steal focus from the previous foreground app. It makes no difference what the foreground app is. It also makes no difference what the "previous app" (Shift+Cmd+Tab) is (i.e. it's not just switching back to the previous app). The 1P application window, even if not-minimized, never appears in the foreground.

If 1P is unlocked but the application window is closed, it does not steal focus. In 1P, I've tried selecting different options in the side bar, putting the cursor in and out of the Search field, etc. to try and eliminate specific 1P starting conditions).

Here's an MP4 if you're interested in the timing of the frequency. Note there's a period about halfway through where it changes very quickly back and forth to 1P. Each time 1P gains focus, I click back in the app (Chrome in this case). 1P is active at the start because it gained focus while I was starting the recording in SnagIt.

It sounds like there is indeed some sort of communication trying to be established. Can you try the following. You mentioned Chrome it might be that it updated. if you've not give it a full quit and check for updates it might shake the cobwebs free.

This issue does appear to be unique to Brave. It does not affect my Chrome or Chromium browsers, or other desktop applications. It seems related, primarily to operating system permissions around Input and application focus mainly, and possibly to graphics & rendering on macOS. I noticed the issue, near as I can tell, when I upgraded to macOS 12.6.1.

3. I can reproduce it. It is a crash that happens during focus merge towards the beginning of the process. It will show about a second or two of the focus merge process and then crash. It doesn't happen every time - this is how I've lived with it: I just keep trying focus merge until it works. I haven't been able to find a pattern. It seems just as likely to happen when I have multiple tabs/docs open as when I have just freshly restarted the app (often after the last crash). Eventually it will work. My focus merges usually have between 10-30 jpegs in them.

It might be a bit of a tricky one for us to replicate based on these conditions as it sounds very much like a local environment issue on your device. For a start could you provide us with some crash reports after running into this crash? FAQ below details how to find these.

I haven't been able to find a pattern. It seems just as likely to happen when I have multiple tabs/docs open as when I have just freshly restarted the app (often after the last crash). Eventually it will work. My focus merges usually have between 10-30 jpegs in them.

If it's more likely to happen with more documents already open in the app perhaps it's memory related. Have you tried closing down All background apps you have running on your mac so it's just Photo 2, closing down any other doc tabs and then running through a few focus merges? Also, have activity monitor open on the Memory so you can see what usages you're hitting during the merge.

To be clear, I've found that it is just as likely to crash when multiple documents/tabs are open as when none are. It appears haphazard in this regard. I'll continue to work while monitoring overall memory usage.

I can now confirm that the crashes still happen when Affinity Photo and Activity Monitor are the only two open apps and memory (as shown in Activity Monitor) is nowhere near being an issue. Also, the latest crash happened when there were only two document tabs open.

c80f0f1006