I've had this issue for the past 2–3 years. It seems to happen because of improper error handling. If you look closely at the app in the instant it opens, your affected account will have a “disconnected” symbol next to it in the sidebar. However, it goes away before an error can be shown.
My theory is: there is a momentary connection issue with these G Suite accounts, and Mail.app starts to show an error by focusing itself, but the error is resolved so quickly it doesn't actually get to show the “connection problems” modal.
I hope this can be fixed soon, it's been a daily annoyance for me for a long time now.
Yet, to force an app to the front when glitch in connection happens is more like a feature they deliriously thought is being useful, instead of choosing other means of notifications, which is plenty.
An app is not forcing itself to the front without someone is specifically writing the code for it to do.
I wrote a SIMBL plugin at one point to neuter applications that did this too much (actually, I forked it from someone who wrote it for Spotify). Trying to grab my attention in a persistent, repetitive way for something that is minor drives me up the wall.
Exactly. I found the bouncing animation genius, as it always reminded me of a toddler impatiently jumping up and down for attention. Doesn't mail.app do this?
Mail.app and most other apps since 10.8 (?) introduced badges just use those, unless it’s a more urgent thing than “you have a new message” in which case, yes, it will bounce the dock icon.
I vaguely remember it having history, but the native system does have something similar in that panel you get by swiping with two fingers from the right edge of the trackpad, in "notifications" tab.
In my experience, if you always hide the Mail window (cmd-h) instead of closing it (cmd-w), it won't ever pop back up. Takes a while to retrain the muscle memory though!
I haven't tested this in Catalina, but it definitely works consistently in Mojave.
This issue has been a real nuisance for at least 5 years and I could never retrain myself. One solution that worked for me was to make it full screen with its own Space.
Mind you, a program with “hidden” windows open takes up more CPU/memory than a program without any windows open, because the view-controllers for those windows are still running, just bound to an invisible, non-updating view. (Though, admittedly, it’s less of a CPU cost than minimizing the window, since that requires the view to be kept active too, to facilitate updating the live thumbnail.)
The main place this comes up is in cases where the main window is doing something clever to gather the information to display itself. For example, Activity Monitor doesn’t suddenly stop using half your CPU when you hide it.
Mail.app probably keeps a big scrollable list-control for the selected view in-memory for as long as you have the window open. So it might be a bad idea to do this if you’re one of those people who never archive anything (i.e. practice “Inbox Infinity.”)
> Though, admittedly, it’s less of a CPU cost than minimizing the window, since that requires the view to be kept active too, to facilitate updating the live thumbnail.
I thought that was a static thumbnail?
> For example, Activity Monitor doesn’t suddenly stop using half your CPU when you hide it.
It does for me, which is why I keep it hidden when I’m not actively using it.
Nah, it updates (...as far as I can recall.) Try opening a chat client, minimizing the chat window, and then sending a message from another device to yourself.
I believe it’s just using the same call into the compositor that Mission Control uses to display your windows and spaces. Those are all live. (They might have a lower update rate, though.)
> It does for me, which is why I keep it hidden when I’m not actively using it.
Interesting. This might be down to Activity Monitor being written to respond to a message letting it know that its view is entirely obscured, and the Activity Monitor main-window view-controller deciding in response that there’s no point in it polling the system if all it’s going to do when re-visible is discard all the stuff it learned in the mean time and re-poll again to get the newest data for the view.
I can’t recall whether Activity Monitor has any historical/time-series views built in? If it does, then if you hide Activity Monitor with those active, it should keep using CPU, to gather the data for that view, whether it’s rendering it or not.
> Mind you, a program with “hidden” windows open takes up more CPU/memory than a program without any windows open
I can’t speak to Mail, but in general a Mac app with no visible windows may actually take zero CPU, because (if it’s written to allow for it) the OS may kill the process entirely.
Solidly on Linux Mint now but back in the day when wrangling MacOS I used Hammerspoon to fix these sort of issues - should be doable to monitor and enforce the background status of Mail.app and then pause the monitoring when invoked by user (easiest thing would likely be to set hotkey that then also pauses monitoring), and finally resume monitoring when Mail.app goes to background (i.e. user done with active interaction).
The author's assessment is incorrect btw, this happened to me frequently for years on a computer without any G suite accounts. On a High Sierra machine fwiw.
My theory is: there is a momentary connection issue with these G Suite accounts, and Mail.app starts to show an error by focusing itself, but the error is resolved so quickly it doesn't actually get to show the “connection problems” modal.
I hope this can be fixed soon, it's been a daily annoyance for me for a long time now.