#347 Alert for incoming calls when Chatpane is hidden or in the background

[Anonymous]

Originally created by: kristofferR

Problem

Chatpane has no call-specific handling. When a call comes in while Chatpane is hidden in the tray, minimized, or behind other apps, the only signal is whatever Messenger's page does on its own: an in-page dialog nobody can see and a ringtone played by the webview. A hidden webview may be throttled or suspended (see [#232] for how WebKit's suspend policy behaves on macOS), so it is not clear the ringtone or any page notification reliably reaches the user. Calls can be missed without anyone noticing.

inject/src/messenger/lib/calls.ts only checks whether the engine supports WebRTC. Nothing detects an incoming call.

Goal

An incoming call is impossible to miss when Chatpane is not in front, and the user can answer or decline it without first finding the window.

Investigation first

Before designing the UI, establish on each platform what actually happens today when a call arrives with the main window hidden, minimized, and behind another app:

• Does the ringtone play?
• Does Facebook raise a web Notification for the call, and does it currently go through chatpane:notify (and therefore get silenced by Mute Notifications)?
• What does the incoming-call dialog look like in the DOM (voice vs video vs group, caller name, Accept / Decline controls)? Extend an MCP probe for this rather than guessing selectors, in the style of the existing notification probes.
• How long does detection take with the window hidden?

Design sketch

• Detect the incoming-call dialog in the page and emit a dedicated event (for example chatpane:incoming-call / chatpane:call-ended), separate from message notifications.
• Show a native alert that stays visible while ringing: caller, call type (voice / video / group, with the group name), and Answer / Decline actions that drive the page's own controls. Answer brings the window forward.
• Dismiss the alert when the page dialog closes (answered elsewhere, caller hung up, timeout).
• Request attention while ringing (Dock bounce on macOS, taskbar flash on Windows, urgency hint on Linux). On macOS, use UserAttentionType::Critical, which keeps the Dock icon bouncing; message notifications use Informational, a single bounce.
• Use each platform's own call presentation where it exists:
• Windows: a toast with scenario="incomingCall" stays on screen, loops a ringtone (ms-winsoundevent:Notification.Looping.Call) and shows large Answer and Decline buttons. Built on the existing windows/toast.rs.
• macOS: a notification with the timeSensitive interruption level gets through Focus even when the caller isn't on the allowed list. Needs the com.apple.developer.usernotifications.time-sensitive entitlement and macOS 12+. It doesn't stay on screen, so the Dock bounce matters.
• Linux: urgency critical (2), which most daemons keep on screen until dismissed, plus action buttons.
• Calls are not message notifications: Mute Notifications and per-conversation mute policy should be decided explicitly for calls, not inherited by accident.
• Only alert when Chatpane is not focused; when the window is in front, Messenger's own dialog is enough.
• Skip on builds where calls are unsupported (#345).

Verification

• Unit-test the dialog classification (voice / video / group, ended) against recorded DOM shapes.
• Real calls on each platform: hidden, minimized, behind another app, and focused; answer and decline from the native alert; caller hangs up before answering; call answered on another device.
• No stuck alert or ringing after the call ends.