Surface the taskbar widget's hidden state in Settings

[diogochaves]

First step toward #261: the native taskbar strip can be hidden by placement outcomes (VerifiedNoFit, persistent TransientLandmarks) with no feedback anywhere, which makes it look broken — especially under taskbar mods. This PR makes those states visible in Settings without changing any placement behavior or defaults.

What changed

• The Settings "Taskbar Usage" group now shows a live status row: "Shown on N taskbar(s).", "Hidden: no free space on the taskbar between Widgets and Start.", "Waiting for taskbar landmarks (Start button not found). A taskbar mod may be interfering.", or "No enabled providers to show." The row is hidden when the widget is disabled (or on non-Windows).
• Backend: prepare_widgets' stringly errors became a typed PrepareFailure enum; the watchdog's completion path maps each pass to a TaskbarWidgetStatus stored next to the host state. Transient landmark misses are debounced (6 consecutive watchdog ticks, ~30s) before reporting "waiting", mirroring the existing keep-the-widget-visible policy, so a Start/Search flyout opening never flashes the row.
• A payload-less taskbar-widget-status-changed event (same idiom as settings-changed) plus a get_taskbar_widget_status command; the row re-fetches on event. Emitted only on actual status transitions.
• Status is set only after apply_prepared succeeds, so the row can never newly claim "shown" when the Win32 side failed; an existing "Shown" status persists through a transient apply failure until the next conclusive outcome (the watchdog retries every 5s).

No placement logic changed; all pre-existing tests pass unmodified. New unit tests cover the status mapping and debounce (pure, no Win32) and the Settings row rendering per status.

Interesting data point while validating: with Windhawk's "Start button always on left" active, the reported state is the no-fit one, not waiting — Start stays discoverable when pinned left; it's the collapsed lane that hides the strip. That matches the analysis in #261.

Commands run

cargo fmt --all
cargo test --manifest-path rust\Cargo.toml
cargo test --manifest-path apps\desktop-tauri\src-tauri\Cargo.toml
cargo clippy --manifest-path rust\Cargo.toml --all-targets -- -D warnings
cargo clippy --manifest-path apps\desktop-tauri\src-tauri\Cargo.toml --all-targets -- -D warnings
pnpm --dir apps/desktop-tauri test
pnpm --dir apps/desktop-tauri run build

All green: 872 + 491 Rust tests, 488 frontend tests, clippy clean with -D warnings, tsc + vite build OK.

Screenshots

Widget visible (normal taskbar):

Widget hidden under Windhawk "Start button always on left" — previously silent, now explained:

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Added taskbar widget status reporting in Settings.
  • Displays guidance for unavailable, disabled, waiting, or unsupported widget states.
  • Shows the number of active taskbars when the widget is running.
  • Updates status automatically when taskbar widget visibility changes.

• Bug Fixes

  • Prevents temporary landmark detection issues from immediately disrupting existing widgets.
  • Preserves the last known status when status checks temporarily fail.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 5c7cdb2e-80c5-481b-8528-51fe414bd602

📥 Commits

Reviewing files that changed from the base of the PR and between 1d54558 and 6eda2a1.

📒 Files selected for processing (1)

• apps/desktop-tauri/src-tauri/src/taskbar_widget.rs

🚧 Files skipped from review as they are similar to previous changes (1)

• apps/desktop-tauri/src-tauri/src/taskbar_widget.rs

---

📝 Walkthrough

Walkthrough

The taskbar widget now exposes typed availability and activity states through Tauri. Native status changes emit events, transient landmark failures use six-cycle debouncing, and the settings UI displays status-specific guidance with native and frontend test coverage.

Changes

Taskbar widget status

Layer / File(s)	Summary
Native status model and recovery apps/desktop-tauri/src-tauri/src/taskbar_widget.rs	The native widget maps preparation outcomes to typed statuses, debounces transient landmark failures, preserves existing widgets during recovery, persists status changes, and tests the status behavior.
Tauri command and event bridge apps/desktop-tauri/src-tauri/src/events.rs, apps/desktop-tauri/src-tauri/src/main.rs, apps/desktop-tauri/permissions/commands.toml, apps/desktop-tauri/src/lib/tauri.ts, apps/desktop-tauri/src/types/bridge.ts	The status command, permission, event, bridge type, and TypeScript wrapper expose native taskbar status to the frontend.
Settings status display and validation apps/desktop-tauri/src/floatbar/SettingsSection.tsx, apps/desktop-tauri/src/floatbar/SettingsSection.test.tsx	The settings section retrieves and refreshes status, maps states to accessible messages, preserves the last known status after read failures, and tests display conditions and request ordering.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant TaskbarWidget
  participant Tauri
  participant SettingsSection
  TaskbarWidget->>Tauri: emit TASKBAR_WIDGET_STATUS_CHANGED
  SettingsSection->>Tauri: invoke get_taskbar_widget_status
  Tauri->>TaskbarWidget: get_taskbar_widget_status
  TaskbarWidget-->>Tauri: TaskbarWidgetStatus
  Tauri-->>SettingsSection: TaskbarWidgetStatus

Loading

Possibly related issues

• [Feature]: Anchored placement for the taskbar usage strip (tray-adjacent), tolerant of taskbar mods #261: Addresses taskbar widget diagnostics for missing landmarks and no-fit placement, which this change maps to explicit status states.

Possibly related PRs

• tsouth89/ceiling#20: Introduced the taskbar widget implementation extended by this status and recovery work.
• tsouth89/ceiling#26: Introduced the Tauri command allowlist extended by the new status command.

Suggested reviewers: tsouth89

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 83.33% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes surfacing taskbar widget hidden status in Settings, which is a central part of the changes.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

apps/desktop-tauri/src-tauri/src/taskbar_widget.rs (1)

690-696: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Report NoProviders when native mode is enabled without a configured provider.

When native_mode_enabled(settings) is true and native_mode_has_configured_provider(settings) is false, this branch sets TaskbarWidgetStatus::Disabled. The Settings UI hides Disabled, so users do not receive the required no-provider guidance. Set TaskbarWidgetStatus::NoProviders for this case.

Proposed fix

-        if native_mode_enabled(settings) && native_mode_has_configured_provider(settings) {
+        if native_mode_enabled(settings) && native_mode_has_configured_provider(settings) {
             schedule_recovery(app);
         } else {
             hide_existing();
             TRANSIENT_STREAK.store(0, Ordering::Release);
-            set_status(app, TaskbarWidgetStatus::Disabled);
+            let status = if native_mode_enabled(settings) {
+                TaskbarWidgetStatus::NoProviders
+            } else {
+                TaskbarWidgetStatus::Disabled
+            };
+            set_status(app, status);
         }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/desktop-tauri/src-tauri/src/taskbar_widget.rs` around lines 690 - 696,
Update the native-mode status branching around native_mode_enabled and
native_mode_has_configured_provider so enabled mode without a configured
provider calls set_status with TaskbarWidgetStatus::NoProviders instead of
Disabled. Preserve the existing recovery behavior for configured providers and
cleanup/reset behavior in the fallback path.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@apps/desktop-tauri/src/floatbar/SettingsSection.tsx`:
- Around line 125-135: Update refreshTaskbarStatus in the useEffect to track an
incrementing request sequence and apply a resolved status only when it is from
the latest request and the effect is not cancelled. Preserve the existing
last-known status behavior on failures, and add a deferred-promise test that
resolves two status reads in reverse order to verify the older result is
ignored.

---

Outside diff comments:
In `@apps/desktop-tauri/src-tauri/src/taskbar_widget.rs`:
- Around line 690-696: Update the native-mode status branching around
native_mode_enabled and native_mode_has_configured_provider so enabled mode
without a configured provider calls set_status with
TaskbarWidgetStatus::NoProviders instead of Disabled. Preserve the existing
recovery behavior for configured providers and cleanup/reset behavior in the
fallback path.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: ca5acdc8-ab56-4cae-8806-081b263111cb

📥 Commits

Reviewing files that changed from the base of the PR and between 09fdf11 and ae675f1.

📒 Files selected for processing (8)

• apps/desktop-tauri/src-tauri/permissions/commands.toml
• apps/desktop-tauri/src-tauri/src/events.rs
• apps/desktop-tauri/src-tauri/src/main.rs
• apps/desktop-tauri/src-tauri/src/taskbar_widget.rs
• apps/desktop-tauri/src/floatbar/SettingsSection.test.tsx
• apps/desktop-tauri/src/floatbar/SettingsSection.tsx
• apps/desktop-tauri/src/lib/tauri.ts
• apps/desktop-tauri/src/types/bridge.ts

[diogochaves]

Both review findings are addressed in e258d37:

• NoProviders when native mode is enabled without a configured provider — valid catch. apply_state's hidden branch now reports NoProviders when native_mode_enabled is true and Disabled only when the toggle is actually off, via a small pure helper (status_when_hidden) with a unit test. The Settings row now gives the no-provider guidance instead of staying silent.
• Stale status reads — the Settings row now tracks a request sequence and only the latest read may write, with a deferred-promise test resolving two reads in reverse order.

The branch is also rebased onto current main (8de324e, post-1.5.29 prep); full suite green after the rebase: 872 + 500 Rust tests, 507 frontend tests, clippy clean with -D warnings.

[tsouth89]

This is really nicely done — thank you. Pulling the status mapping and debounce out into pure functions so a Win32-bound module can actually be unit-tested is the part I appreciated most, and the widgets.is_empty() && rejected_taskbars.is_empty() split between "conclusively no fit" and "landmarks not visible right now" is exactly the right line to draw. The Windhawk data point is a useful confirmation of the #261 analysis too.

Heads up that 1.5.29 landed changes in taskbar_widget.rs since you opened this, so I merged main into your branch locally and ran everything: 500 Rust tests, 507 frontend, clippy -D warnings, fmt and tsc all clean. No conflicts, nothing to worry about — I'll update the branch here.

Two small things, neither blocking:

1. set_status treats a poisoned STATUS lock as "no change" and current_status() falls back to Disabled, which hides the row entirely. Unlikely given how small the critical section is, but the failure mode is a permanently silent status row, which is the one thing this feature exists to prevent. unwrap_or_else(|e| e.into_inner()) in both spots would make it fail visible instead.

2. Tiny wording thing: the description says the row "can never claim 'shown' when the Win32 side failed" — true for a new claim, though an existing Active will persist if a later apply_prepared fails. That's probably the behavior you want for a transient failure, just slightly different from the sentence.

Happy to push (1) myself if you'd rather not bother, but it's your PR and it's a small change, so I'd rather leave it with you.

[diogochaves]

Thanks for merging main in and re-running everything, appreciated.

On (1): agreed, and it's a good catch, a permanently silent status row is the one failure mode this feature exists to remove, so it shouldn't be able to inflict it on itself. Pushed 6eda2a1: set_status and current_status now recover a poisoned lock with unwrap_or_else(|poisoned| poisoned.into_inner()), so a panic elsewhere degrades to a possibly-stale-but-visible status instead of a hidden row. Comes with a test that poisons the lock from another thread and asserts the stored status still comes back.

On (2): you're right, the sentence overclaimed. An existing Active deliberately survives a transient apply_prepared failure (the watchdog retries 5 seconds later), so what's actually guaranteed is that the row never newly claims shown when the Win32 side failed. I've edited the description to say that.