Feature Request: Web Browser Meeting Detection & Recording

[BrodeOne]

Feature Request: Web Browser Meeting Detection & Recording

Hey there,

Just a heads up before jumping in: I'm pretty new to this and I don't want to pretend I know exactly how the codebase handles all the deep macOS APIs. So the technical "how-to" part below is more of a rough logic concept. The "why" is the main thing!

The Problem

Right now, the app is awesome at catching native desktop apps. But we are missing a huge chunk of meetings that happen directly in the browser.

• Platforms like Google Meet and Whereby don't even have native Mac apps.
• A lot of people use the web versions of Teams, Zoom, or Webex because they either don't want to install the heavy desktop apps or their company IT strictly blocks them.

Since the app can't catch these right now, users have to manually click to start recording, which kinda defeats the whole purpose of the auto-detection magic.

How it could work (the basic logic)

Since we can't hook into web apps as easily as desktop apps, I was thinking about a flow like this:

1. Watch the window titles
The app could occasionally (maybe every 3 seconds?) check the open window titles of popular browsers like Chrome, Safari, Edge, Firefox. It would just look for patterns like "Zoom Meeting" or "Standup - Google Meet".

2. Double-check so it doesn't glitch
Because web pages can load slow or people quickly flip through tabs, it probably shouldn't trigger instantly. Maybe it needs to see the meeting title twice in a row (over ~6 seconds) before doing anything. This way it ignores random loading screens.

3. Ask first (No auto-start)
Browser tabs can be messy. Instead of just auto-recording (like it does for desktop apps), it should pop up a simple alert: "Do you want to record this meeting?"

• If they hit Record, it grabs the audio and starts.
• If they hit Ignore, it goes on a 60-second cooldown so it doesn't spam the user with popups.

4. Grabbing the audio
I know browsers like Chrome use a bunch of hidden background processes for rendering audio. When the user hits record, the app would need to target the browser and pull in all its sub-processes to make sure it actually captures the sound, and then mix it the way it normally does.

Settings Menu Updates

To make it user-friendly, we could update the Settings -> Apps to Watch menu:

• Add normal checkboxes for Google Meet and Whereby.
• Add a master toggle for Browser Web Meetings. If a user turns this off, the app completely ignores browser tabs to save resources.

Let me know what you think! Like I said, just pitching the logic here to show what I want to do and why. I know the heavy lifting on the code side is on you, but hopefully, this gives a good starting point!

[pasrom]

This shipped. It was tracked and implemented as #503, which is closed as completed; this thread just never got the reply it deserved. Here is what landed against your proposal.

Detection. Not window titles in the end. The app matches the power assertion a Chromium browser holds during a call: NoIdleSleepAssertion named "WebRTC has active PeerConnections". Better trade than titles, because it needs no Screen Recording permission and does not depend on the tab title or the user's language. Your debounce idea survived: the signal has to hold across several polls before it counts as a meeting.

Ask first. Exactly as you argued. A notification with Record and Ignore, never an auto-start. The cooldown ended up asymmetric: an explicit "no" suppresses the question for 10 minutes, an unanswered prompt only for 1 minute, because silence usually means the user was away from the screen rather than opposed. There is also a "Never for this app" answer, which is permanent and undoable in Settings.

Settings. One master toggle, "Browser Web Meetings", off by default. No separate Google Meet and Whereby checkboxes though: detection happens at the browser level and cannot see which site the call is on, so per-platform switches would promise a distinction the app does not have.

Audio. Handled by the existing multi-PID tap, which targets the browser together with its helper processes, the same path the Electron apps already used.

Where it is. Chrome landed in v0.6.0, v0.7.0 added Brave, Edge and Chromium. On main, and going out with the next release, the browser list disappears entirely: any process holding that assertion is a candidate, so forks like Arc or Aside are detected without a code change, and the consent prompt plus the never-list do the filtering.

Two limits worth knowing. Safari and Firefox are not detected, since both sit outside Chromium's content layer and do not hold that assertion. And a recording captures the browser's entire audio, not only the meeting tab; narrowing that down is a known follow-up.

Thanks for writing it up. The "why" was the part that mattered, and the ask-first flow shipped essentially the way you described it.