Windows: replies to thread/channel-mention notification toasts are silently lost (handleActivation never fires)

[jeanfbrito]

Summary

On Windows, typing a reply into a thread or channel-mention notification toast (or its Action Center card) silently does nothing — the message is never sent. Replies to direct-message toasts work correctly. The toast dismisses on Enter exactly as it does on success, so the user believes the reply was sent.

Discovered during runtime validation of #3464 on a real Windows 10 VM.

Environment

• Rocket.Chat Desktop 4.17.0-alpha.1 (built from fix: Windows notification quick replies lost after toast dismissal #3464, NODE_ENV=production)
• Electron 42.5.0 (contains fix: dispatch toast action and reply events from WinRT activation path electron/electron#51286, the non-MSIX reply-dispatch fix)
• Windows 10, non-MSIX NSIS install, default notification settings
• Server: Rocket.Chat 8.8

Behavior

Toast type	Reply outcome
Direct message	✅ posts correctly (live toast and Action Center)
Thread reply / channel mention (#room title, @user body)	❌ silently lost

Reproduced 4/4 attempts for the thread case; the DM case passed in every run of the same automated scenario.

Instrumented evidence

For the failing case, with CDP attached to the webview and the main process launched with stdout captured:

1. The toast/Action Center card renders correctly with its reply input.
2. The input is verified focused, the text is typed, Enter is pressed, the card dismisses.
3. Notification.handleActivation callback (registered in src/notifications/main.ts) never fires — no type: 'reply' activation arrives.
4. No IPC action reaches the webview (no NOTIFICATIONS_NOTIFICATION_REPLIED).
5. No chat.sendMessage request leaves the app (verified via Network.requestWillBeSent).
6. Neither of the drop-path warnings in handleNotificationActivation (main.ts:269, main.ts:277 — unparseable tag / unknown routing id) is emitted.

So the activation is lost before our handler is invoked at all — i.e. at the Electron/WinRT layer, not in our routing.

Not a regression from #3464

On 4.15.6 no reply of any type was ever delivered (the app dropped the notification instance when the toast auto-dismissed and never registered handleActivation). #3464 fixes DM replies, which is what exposes this deeper, pre-existing gap.

Next steps

1. Minimal standalone Electron 42.5.0 repro: fire paired notifications differing only in title/body shape (DM-like vs #room + @mention) and log handleActivation — isolate which property correlates with the lost activation.
2. If confirmed as an Electron-layer issue, report upstream (closest prior art: action and reply notification events never fire on non-MSIX Windows apps electron/electron#51147, fixed by #51286 — this looks like a sibling gap).
3. Separately: the drop-path console.warn calls in handleNotificationActivation are invisible in packaged builds — switching them to the app logger would make future diagnosis far cheaper.

Context

• Fix PR that exposed this: fix: Windows notification quick replies lost after toast dismissal #3464
• Support ticket: SUP-1097 (customer-reported quick-reply failure; the DM/Action-Center part is fixed by fix: Windows notification quick replies lost after toast dismissal #3464)

[jeanfbrito]

Root cause found — this is ours, not Electron's, and it is a timing bug rather than a thread-specific one

Correcting this issue's premise. A standalone Electron 42.5.0 repro fired six notification shapes (plain title, #room title, @mention body, spaces, long body) and all six activated correctly, including via handleActivation. Electron does not care about notification content, so no upstream issue is warranted.

What actually happens:

1. Windows moves the toast banner into the Action Center after a few seconds. Electron reports this as NotificationDismissed(should_destroy=false) — the platform object stays alive and the card remains repliable — but it still emits the JS close event.
2. Our close listener removed the instance from the notifications map.
3. The web client then auto-closes every notification ~10s after showing it (useNotification.ts:45-48; the server never sends duration, so the fallback is always 10s), which reached our NOTIFICATIONS_NOTIFICATION_DISMISSED handler.
4. That handler called notifications.get(id)?.close() — a no-op, since step 2 already removed it, so the Action Center card was never actually taken down — and then deleted the routing metadata for a card still on screen.
5. A reply from that card then found no routing entry and was dropped.

The DM-vs-thread split was a red herring. There is no room-type branch anywhere in the notification path — dispatchCustomNotification has zero callers in the web client, so DMs, threads and mentions all travel the same route. Composing a thread reply simply takes longer than 10 seconds, so it always lost the race, while faster DM replies landed inside the window.

Fixed in #3464 (51bc3b929): routing metadata is retained past dismissal on Windows (bounded LRU still reclaims it), timed-out instances stay reachable so a dismissal genuinely removes the card, and a broadcast fallback covers real eviction/cold-start instead of dropping the reply. Regression tests cover the delayed-reply case; 55 notification tests green.

Worth raising with the web-client team separately: useNotification.ts unconditionally auto-closes desktop notifications after 10s. On Windows that call cannot remove an Action Center card, so it only serves to desynchronise app state from what the user still sees.

Closing this once #3464 merges — keeping it open until then as the tracking record.