[nu-demo] Purple highlight remains after closing apps #154

New issue

Closed

opened 2026-04-24 01:53:13 +00:00 by scott · 1 comment

scott commented

2026-04-24 01:53:13 +00:00

Owner

Open, then close with the X in the upper right of the window. The "active" highlight remains in the toolbar.

Open, then close with the X in the upper right of the window. The "active" highlight remains in the toolbar. ![image](/attachments/d509cf1a-fd71-4f5f-b2f0-8385abf47ea5)

image.png

22 KiB

mik-tf referenced this issue from a commit

2026-04-27 04:27:25 +00:00

fix(dock): purple highlight clears when archipelago has no open windows

mik-tf referenced this issue from a commit

2026-04-27 04:27:25 +00:00

fix(dock): purple highlight clears when archipelago has no open windows

mik-tf closed this issue

2026-04-27 04:27:25 +00:00

mik-tf commented

2026-04-27 04:28:20 +00:00

Owner

Fixed in hero_os commit 5a811a3 on development.

Reproduction — live on herodemo (1920×1080) via Hero Browser MCP:

Click Media in the dock → submenu opens, Media dock-btn gets background: rgba(139, 92, 246, 0.15) ✓
Click Photos in the submenu → Photos opens, popup closes
Close the Photos window via the X — island.window-shadow count drops to 1 (Contexts only)

Inspect dock state:

{"text":"Intelligence","bg":""}, {"text":"Communicatio","bg":""}, {"text":"Files","bg":""},
{"text":"Media","bg":"rgba(139, 92, 246, 0.15)"},  ← stale highlight
{"text":"Store","bg":""}, ...

Root cause — dock.rs:415-435:

let is_popup_open = open_popup.read().as_ref().map(|(id, _)| id) == Some(&arch_id);
let button_style = format!("…;{bg}",
    bg = if is_popup_open { " background: rgba(139, 92, 246, 0.15);" } else { "" },
);

The popup state IS cleared at dock.rs:577 when an island is clicked from the popup — but the surrounding dock-btn render block doesn't reactively invalidate against that update under Dioxus 0.7's signal model when the parent's per-archipelago for loop re-runs. The inline-style background therefore sticks at rgba(...) even after the popup is gone.

Fix — derive highlight from BOTH signals OR'd together:

let is_active = archipelago_has_focused_window(&arch_id);
let highlight_active = is_popup_open || is_active;

archipelago_has_focused_window was already being read at this site (under the unused-suppressing _is_active name, only consumed for the small dot indicator below the icon). It's backed by the live window-registry signal, so closing the last window of an archipelago immediately turns it false — the highlight clears cleanly. Both names were updated to is_active since it's now used in two places.

State matrix:

State	`is_popup_open`	`is_active`	highlight
popup just opened, no window yet	true	false	✓
popup item clicked, window opens	false	true	✓
last window closed via X	false	false	clears ✓

Verification: cargo check -p hero_os_app --features web clean. Visual confirmation deferred to next deploy of hero_os to herodemo.

Sidebar finding — the parallel verification for home#146 (Photos <img> not rendering) revealed it's actually a duplicate symptom of home#156: the rendered URLs come out as …/api/files/geomind//Photos/beach_retreat.jpg (note the double slash from leading-slash storage_path), which webdav 403s. Single-slash URL serves 200. Tracking under home#156 instead.

Meta-tracker: home#193.

Signed-off-by: mik-tf

Fixed in hero_os commit `5a811a3` on `development`. **Reproduction** — live on herodemo (1920×1080) via Hero Browser MCP: 1. Click Media in the dock → submenu opens, Media dock-btn gets `background: rgba(139, 92, 246, 0.15)` ✓ 2. Click Photos in the submenu → Photos opens, popup closes 3. Close the Photos window via the X — `island.window-shadow` count drops to 1 (Contexts only) 4. Inspect dock state: ``` {"text":"Intelligence","bg":""}, {"text":"Communicatio","bg":""}, {"text":"Files","bg":""}, {"text":"Media","bg":"rgba(139, 92, 246, 0.15)"}, ← stale highlight {"text":"Store","bg":""}, ... ``` **Root cause** — `dock.rs:415-435`: ```rust let is_popup_open = open_popup.read().as_ref().map(|(id, _)| id) == Some(&arch_id); let button_style = format!("…;{bg}", bg = if is_popup_open { " background: rgba(139, 92, 246, 0.15);" } else { "" }, ); ``` The popup state IS cleared at `dock.rs:577` when an island is clicked from the popup — but the surrounding dock-btn render block doesn't reactively invalidate against that update under Dioxus 0.7's signal model when the parent's per-archipelago `for` loop re-runs. The inline-style `background` therefore sticks at `rgba(...)` even after the popup is gone. **Fix** — derive highlight from BOTH signals OR'd together: ```rust let is_active = archipelago_has_focused_window(&arch_id); let highlight_active = is_popup_open || is_active; ``` `archipelago_has_focused_window` was already being read at this site (under the unused-suppressing `_is_active` name, only consumed for the small dot indicator below the icon). It's backed by the live window-registry signal, so closing the last window of an archipelago immediately turns it false — the highlight clears cleanly. Both names were updated to `is_active` since it's now used in two places. State matrix: | State | `is_popup_open` | `is_active` | highlight | |-------|:--:|:--:|:--:| | popup just opened, no window yet | true | false | ✓ | | popup item clicked, window opens | false | true | ✓ | | last window closed via X | false | false | **clears** ✓ | Verification: `cargo check -p hero_os_app --features web` clean. Visual confirmation deferred to next deploy of hero_os to herodemo. **Sidebar finding** — the parallel verification for home#146 (Photos `<img>` not rendering) revealed it's actually a duplicate symptom of home#156: the rendered URLs come out as `…/api/files/geomind//Photos/beach_retreat.jpg` (note the double slash from leading-slash storage_path), which webdav 403s. Single-slash URL serves 200. Tracking under home#156 instead. Meta-tracker: home#193. Signed-off-by: mik-tf