[huacnlee]

Description

On Windows, Notifications.requestPermission() answered unavailable and Notifications.show() showed nothing for an app that had never shown a notification, which is every app on its first run.

An unpackaged app has no entry in Settings > System > Notifications until its first toast, and ToastNotifier.Setting fails with ERROR_NOT_FOUND (0x80070490) until then. The backend treated that error as "cannot read the setting": the permission was unavailable and show refused, so the first toast that would create the entry was never sent.

A missing setting now reads as enabled: the user has turned nothing off. A real Disabled* setting still answers denied.

Testing

Windows 11 VM (fresh user, no notification settings for the app), gallery → Notifications under nsh test --target windows, dev host cross-built with cargo xwin:

• Before: the log showed notifications: cannot read the setting: Element not found. (0x80070490), the permission badge said unavailable, and Show gave "Not shown: allow notifications first".
• After: the permission is granted, Show brings the toast up in the corner ("Ada — Are you coming tonight?"), and the badge on the taskbar button counts 3 after three Add one.
• cargo xwin clippy --target x86_64-pc-windows-msvc -p nsh-platform-windows --all-targets.

🤖 Generated with Claude Code

Additional Windows verification screenshots

Windows guest inside Omarchy, gallery on main 8004f8681 (includes #1009 and #1010), fresh app ID dev.nsh.o8test1339.

First notification

Permission is granted; Show displays a toast with the O8Gallery name and app icon. The taskbar icon is visible at 100% scale.

App notification disable / re-enable

Left: app notifications disabled through the registry, permission is denied and Show is blocked. Right: re-enabled through the registry, but permission still reads denied.

After relaunch

Permission still reads denied after relaunching the app following the registry changes.

The disable/re-enable checks used registry writes rather than the Windows Settings switches. The cause of the persistent denied state is unconfirmed; this does not establish an NSH defect. Verification with the actual Settings switches remains pending.

🤖 Noop (lead) · AI agent acting for @huacnlee

[huacnlee]

Applied the shared menu focus fixes and merged main normally, preserving this branch's ancestry. Order watchers skip identity permutations, so pending focus must also be applied when menu items are laid out. Chromium additionally reports Shift+F10 context menus as pointerType: "mouse", button: -1; recognizing that as keyboard input gives the first item focus. These fixes add no public API or dependencies.

Shared-fix validation on Linux: CLI build, workspace check, targeted menu/CLI/JS Clippy with --all-targets -D warnings, 1,698 base tests on #1010, all 294 Gallery tests, all 63 Web unit tests, and cargo xtask compat against every recorded release. Real Chromium passed all three context-menu tests and an additional desktop-viewport keyboard test; a screenshot step also verified Space selects the item.

This branch passed targeted check and Clippy. Its base suite initially failed three focus-within cases; all three passed isolated reruns. Main also reproduces focus-within failures, including Carousel and HoverCard.

Full workspace tests and Clippy also ran. Unmodified main reproduces the shader-frame failure, six TUI failures, math-enabled formula-test failure, and Web test field_reassign_with_default lint. Focus-within tests also show timing-sensitive failures on main. Three bundler fixture tests hit the sandbox's read-only home cache. These broader checks are not being reported as fully passing. Native Windows/macOS execution has not been verified on this Linux host.

🤖 Noop (rust-maintainer) · AI agent acting for @huacnlee

[huacnlee]

✅ No code blocker found in the Windows first-toast fix at 400b614b4; independent live Windows verification remains pending.

The private setting helper normalizes only ERROR_NOT_FOUND from ToastNotifier.Setting. Registration/notifier creation errors and other HRESULTs still propagate; explicit Disabled* values still produce denied and prevent sending. Both the permission and show paths use the same helper. No public API or dependency change. This is consistent with Microsoft’s documented setting states.

Verification: serial cross-Clippy of the actual Windows backend with cargo xwin clippy --target x86_64-pc-windows-msvc -p nsh-platform-windows --no-default-features --all-targets -- -D warnings passed. Changed Rust files pass nightly rustfmt and diff whitespace checks; Web unit tests pass 63/63. Full formatting check reports five files unchanged from merge base f7afd23f5. All current CI checks pass (website deploy intentionally skipped), including native Windows Clippy/tests; the shared menu prerequisite’s broader validation is already documented above.

The PR’s Windows 11 fresh-user before/after observation is author evidence. This Linux reviewer has not independently displayed the first toast or tested notification Settings. Remaining native check: fresh app ID → granted permission and first toast; then per-app/global notification disable → denied and no toast; reenable and restart → normal behavior. Capture the actual toast and permission state for the before/after comparison. The Windows example CI does not exercise this notification demo.

🤖 Noop (reviewer) · AI agent acting for @huacnlee