[z1pp090]

Closes #1780.

The bug

Clicking a notification that came from a Win32 app with a dedicated toast AUMID fails with:

Windows cannot find shell:AppsFolder\FirefoxToast-308046B0AF4A39CB

It is not specific to Firefox. Enumerating HKCU\SOFTWARE\Classes\AppUserModelId on my machine returns four registrations and three of them declare a CustomActivator: Firefox, FanControl and DSX.

Root cause

Two things chain together, both in src/background/modules/notifications/application.rs.

1. clean_toast synthesizes a launch target that cannot resolve, and forces the wrong activation type.

if toast.launch.is_none() {
    toast.launch = Some(format!("shell:AppsFolder\{umid}"));
    toast.activation_type = ToastActionActivationType::Protocol;
}

The shell:AppsFolder namespace only enumerates packaged apps, so a Win32 toast AUMID is never in it — hence the shell error. And forcing Protocol sends the click down the open_file_inner branch of activate_notification, which means the INotificationActivationCallback path is skipped entirely, even though that is the correct way to activate these toasts.

2. Even when reached, the CLSID lookup cannot find them.

get_toast_activator_clsid resolves non-packaged AUMIDs by looking them up in the start menu index and reading PKEY_AppUserModel_ToastActivatorCLSID from the shortcut. An AUMID that exists only for toasts has no shortcut carrying it, so the lookup always misses.

The fix

• Only synthesize the shell:AppsFolder launch for packaged apps. For Win32 apps launch stays empty, so activate_notification falls through to the COM activator that already exists.
• Read CustomActivator from SOFTWARE\Classes\AppUserModelId\<aumid> (HKCU first, then HKLM, matching how the shell resolves Classes) before falling back to the shortcut lookup.

This is the documented registration point for desktop toasts with a COM server. No new dependencies — winreg was already in use.

Testing

Continuous Integration was run on my fork before opening this: js-test-and-linter, rust-linter and rust-test all pass.

Not yet verified at runtime. I do not have a local build environment for this project, so the change has not been exercised against a real toast on my machine. The reasoning is derived from the registry evidence in #1780 and from reading the activation path. Runtime confirmation from someone who can build it, or from a nightly, would be welcome before merging.

🤖 Generated with Claude Code