Improve Windows downloads, account switching, and notification activation

[matheuscardosoj]

Changes

Windows downloads now ask where to save each file and cancel when the save dialog is dismissed. Clicking a notification reveals the account that generated it while respecting the app lock.

• Preserve the preferred startup account setting and compatibility with existing account configuration.
• Add a keyboard-accessible account selector to the WhatsApp header, with unread counts and narrowly scoped remote-window permissions.
• Restore the selector when WhatsApp replaces its header, avoiding overlap with the navigation sidebar.
• Integrate the current upstream and fix Windows compilation and notification handling.
• Configure a Portuguese Windows NSIS installer for the current user with a Start menu folder.
• Update notification test stubs and expectations to match the integrated bridge behavior.

Validation

• Windows release build and NSIS installer generation completed successfully (tauri build --bundles nsis -- --locked).
• Confirmed that the application and installer use the Windows GUI subsystem.
• Rust tests: 102 passed during implementation validation.
• Existing bridge, hotkey, and settings-dialog suites passed; notification suite: 4 passed.
• Browser checks with the real bridge and a simulated WhatsApp header passed at widths 560, 900, and 1920, including keyboard account selection, Escape/focus restoration, and header replacement.

Remaining validation

Draft pending end-to-end checks in the installed Windows application: actual WhatsApp header placement, file drag-and-drop, Save As/cancellation/duplicate filenames, notification activation across accounts, and locked-app behavior. macOS and Linux have not been validated locally. The generated installer is a local artifact and is not attached to this PR.

[Copilot]

🟡 Changes recommended

There is at least one likely compile-breaking issue (missing tauri::Manager import for app.config() in aumid.rs) that should be fixed before approval.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR addresses Windows toast notification failures and several multi-account startup/locking edge cases by tightening Tauri ACL permissions, surfacing bridge IPC failures, and adjusting window-creation sequencing to avoid WebView2 deadlocks.

Changes:

• Add explicit custom command permissions/capabilities for the WhatsApp bridge, Settings, and lock windows; log bridge IPC failures without leaking message contents.
• Serialize account mutations and adjust window creation/focus flows (Settings + lock) to reduce WebView2 deadlock risk and enforce lock gating.
• Persist and expose a “default startup account” selection in Settings UI, plus small UX fixes (select option theming, idempotent autostart disable).

File summaries

File	Description
src-tauri/src/window.rs	Gate account showing behind lock; serialize Settings window creation and improve error logging/visibility behavior.
src-tauri/src/settings.rs	Make autostart disable idempotent to avoid Windows “NotFound” failures when already off.
src-tauri/src/lock.rs	Serialize lock window creation off synchronous callbacks; avoid stale lock window if unlock races creation.
src-tauri/src/lib.rs	Add --settings single-instance behavior; prioritize startup account window visibility; defer some tray/settings work off setup.
src-tauri/src/commands.rs	Add persisted startup default selection plumbing; serialize account mutations; move account commands to async.
src-tauri/src/aumid.rs	Minor cleanup around Windows AUMID registration setup.
src-tauri/src/accounts.rs	Persist startup_account preference with validation + tests; add global mutation mutex.
src-tauri/resources/notifications.test.mjs	New Node tests covering notification/unread routing and IPC failure logging behavior.
src-tauri/resources/bridge.js	Log IPC failures (without payload), forward SW notifications, and ensure unread updates are invoked.
src-tauri/permissions/app.toml	Define custom command permissions for bridge/settings/lock to participate in ACL checks.
src-tauri/capabilities/settings.json	Grant Settings window capability the new settings-command permission.
src-tauri/capabilities/main-remote.json	Assign the WhatsApp remote capability to the new bridge permission set.
src-tauri/capabilities/lock.json	Grant lock window capability the new lock-command permission.
settings-ui/style.css	Force readable native <option> colors across themes; improve account row wrapping.
settings-ui/main.js	Add “default startup account” selector and serialize UI actions with a busy state + status messages.
settings-ui/index.html	Add default startup account field + live status note region for account actions.

Review details

• Files reviewed: 16/16 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[karem505]

Thanks, @matheuscardosoj. Your diagnosis here was right: the remote page's custom commands were being refused by the ACL, and the bridge swallowed the rejection. Part of this PR has since landed on master in a different form, but part of it hasn't, so I'm leaving it open rather than closing it as superseded.

Already on master (v0.6.4 to v0.6.6):

• ACL grants. These come from an app manifest in build.rs (tauri_build::AppManifest::commands), with allow-<cmd> permissions in the main-remote, settings and lock capabilities. Linux-only mock-runtime tests in ipc_acl_tests.rs assert what each window may and may not call.
• IPC failures are logged by the bridge, without arguments or message content.
• Windows notifications are confirmed working on v0.6.5 (Notification Doesn't Appear #3). The last piece was granting WebView2's own notification permission.
• The Settings window was redesigned (UX -> better download feedback and a more native Settings layout #21), so the select/option colour fix and the old account-row markup no longer apply.

Not on master, and still worth having:

1. Creating windows off the UI thread. On master, add_account, open_account, rename_account and remove_account are still synchronous commands that can build a WebView2 window inline (the wry #583 deadlock), and so is open_settings_window from the tray. Your async commands + MUTATION lock, and the spawn-blocking settings and lock window creation, are the fix.
2. A persisted startup account (startup_account + set_default_account), with its tests.
3. A no-op autostart "disable" when it's already disabled (the Windows NotFound).
4. The lock-window race: destroying a lock window created after unlock had already succeeded.

The branch now conflicts heavily with master: capabilities, bridge.js, the Settings UI, commands.rs and lib.rs. If you're up for it, rebasing just items 1–4 onto current master, as one PR or a few small ones, would make this straightforward to review and merge. Please drop the ACL, bridge and CSS parts. If you'd rather not, let me know and I'll port items 1 and 3 myself, with credit.

---

Generated by Claude Code