Notifications appear in Zoom screen sharing on Big Sur 11.1

[karlhorky]

On Big Sur - macOS 11.1 (20C69), notifications appear in Zoom 😵 while screen sharing (with Muzzle 1.7 and Zoom Version: 5.4.9 (59931.0110)).

I have disabled the built-in Zoom option "Silence system notifications when sharing desktop":

And also allowed Muzzle under Privacy -> Accessibility:

[karlhorky]

So, one more detail that is probably relevant here:

I have the setting checked in macOS System Preferences "Automatically hide and show the menu bar":

If I hover over the menu bar while starting the Zoom screen sharing, then Muzzle activates Do Not Disturb as it should 🤯

So maybe this is a bug with the menu bar not being visible...

[karlhorky]

Workaround: Until Muzzle works with Big Sur 11.1 (and maybe even after, if I can find an npm module that reliably checks for the "screen sharing" status), here's a working npm package that will run in the background and disable and enable Do Not Disturb when a Zoom call starts:

https://github.com/karlhorky/do-not-disturb-during-zoom-macos

cc @dan2k3k4

[bdkjones]

@karlhorky Ahhhh, that's the issue. Your menubar must be visible for Muzzle to work. I'll update the app's documentation to say so and I'll see if I can add an in-app warning when the menubar isn't visible.

The reason for this is that there is no approved Apple API to toggle DND on and off. This leaves only one approach: the accessibility API that inspects UI elements to provide services such as Voiceover and screen readers, etc. For that API to work, the UI element in question must be on screen—in this case, the menu bar.

[karlhorky]

Hmm, I think there are a few ways of achieving it without the menu bar visible (eg. the one that is working in my repo above).

This thread outlines some approaches. The one I use is at the bottom:

sindresorhus/do-not-disturb#9 (comment)

[karlhorky]

Ah and by the way, would you be open to sharing the low-level hook in macOS you use to see whether screen sharing is being used? Wasn't able to find a solution for that in a quick search...

[bdkjones]

Yep, I’m well aware of what the Javascript folks do. You see that `killall` statement in there? That's an incredibly brute-force, abusive way to interface with the system. And, as you’ve discovered, your approach supports only one version of macOS. Muzzle has worked on 10.12, 10.13, 10.14, 10.15 and 10.16 — WITHOUT beating the system in the face with a 2x4 repeatedly.

…

On 31 Jan 2021, at 01:37, Karl Horky ***@***.***> wrote: Hmm, I think there are a few ways of achieving it without the menu bar visible (eg. the one that is working in my repo above). This thread outlines some approaches. The one I use is at the bottom: sindresorhus/do-not-disturb#9 (comment) <sindresorhus/do-not-disturb#9 (comment)> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#90 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHCGZW2MAKEMTPROGKTOGTS4UQEZANCNFSM4W2LMJAA>.

[bdkjones]

The kernel hook I use wouldn't work in npm land. There is no way to interface with it from Javascript. Finding a way to interface with hidden, private kernel APIs from a Javascript engine would win you the million dollar bug bounty!

[bdkjones]

I should add: you're not at all wrong; there are many different ways to toggle DND on and off, given that there is no official API to do so. I have used a variety of approaches over the last five years as the OS changed.

On balance, accepting that Muzzle does not work with the menubar hidden is a better alternative than modifying part of a private plist and then nuking system processes to clear caches. Will that approach produce side effects? Maybe, maybe not. Will it be safe in future updates to the OS, when that system process changes and is now more critical? Who knows?

Muzzle is a good Mac citizen. It does use private APIs, but it works in a safe way that I know will never break anyone's machine or corrupt state or suddenly implode with the next point-release of macOS. Muzzle has millions of installs and I take that footprint seriously. If I fuck up, there's gonna be a lot of angry people with pitchforks.

I want folks to know they can trust my work and part of that means not doing things that are (or could become) risky. That calculus is different when you have a script that you're running on YOUR Mac, and not millions of other folks' machines. For tools that I don't ship widely, I'll bash macOS in the face all day long. I just can't do that with Muzzle.

[karlhorky]

Seems reasonable, I understand what you're saying. Tradeoffs are hard, and your approach of assuming for stable methods sounds nicer compared to the brute force options.

[karlhorky]

The kernel hook I use wouldn't work in npm land. There is no way to interface with it from Javascript. Finding a way to interface with hidden, private kernel APIs from a Javascript engine would win you the million dollar bug bounty!

I was actually thinking of writing some code in another language for this (obj C or Swift) and then providing bindings to that in JS so many more could use it.

Would you be willing to share the private API that Muzzle uses?

[aaronjensen]

It's not clear what the status is on this--there have been a few releases that claim to fix it, but on macOS 11.4 with Muzzle 1.9 I still see the notifications appear and disappear any time it activates, regardless of whether or not it's zoom. Is there anything I can do to help?

[bdkjones]

Someone reported that it's not actually Muzzle's fault. It's a bug in macOS. Option-click the clock icon (to toggle DND) and you'll see that the notifications drawer hides/shows. I've reported the issue to Apple, but Apple is busy finding new ways to make my Airpods Max connect to every device except the one I want it to connect to, so I wouldn't hold my breath.