Stale search text silently empties a freshly opened folder view; count footer disagrees #602

New issue

Closed

opened 2026-09-18 10:25:05 +00:00 by Cordy · 1 comment

Cordy commented

2026-09-18 10:25:05 +00:00

Owner

Found while eyeballing #571 on the enc dogfood (v0.6.215).

Repro

Type anything in the top searchbox (e.g. admin1) and leave it there.
Navigate via the sidebar: Shares → Shared with me → open a shared folder (also reproduces on normal folder navigation).
The list body renders zero rows — the rows are in the DOM with inline display: none from the client-side filter — while the count footer still reads the unfiltered totals ("0 folders, 2 files").

Why it's bad

No indication anywhere that a filter is active on the new view; it looks like the folder is empty or broken.
The footer contradicts the visible list, which reads as data corruption to a user.

Suggested fix (pick one)

A: clear the searchbox on any route/folder change (search is per-view, the common convention), or
B: keep the filter but make it honest — footer counts the visible rows and the view shows a "filtered by 'X' — clear" affordance.

A is simpler and matches how the header search already spawns a dedicated "Results for 'X'" view; the sticky text seems to be leftover state, not a feature.

Found while eyeballing #571 on the enc dogfood (v0.6.215). **Repro** 1. Type anything in the top searchbox (e.g. `admin1`) and leave it there. 2. Navigate via the sidebar: Shares → Shared with me → open a shared folder (also reproduces on normal folder navigation). 3. The list body renders zero rows — the rows are in the DOM with inline `display: none` from the client-side filter — while the count footer still reads the unfiltered totals ("0 folders, 2 files"). **Why it's bad** - No indication anywhere that a filter is active on the new view; it looks like the folder is empty or broken. - The footer contradicts the visible list, which reads as data corruption to a user. **Suggested fix (pick one)** - A: clear the searchbox on any route/folder change (search is per-view, the common convention), or - B: keep the filter but make it honest — footer counts the visible rows and the view shows a "filtered by 'X' — clear" affordance. A is simpler and matches how the header search already spawns a dedicated "Results for 'X'" view; the sticky text seems to be leftover state, not a feature.

Cordy added this to the v0.7 — Closed beta (dogfood + hardening) milestone

2026-09-18 17:24:35 +00:00

forgejo-actions referenced this issue from a commit

2026-09-18 19:15:04 +00:00

#602: clear stale search text on route/folder change (fix A)

forgejo-actions referenced this issue from a commit

2026-09-18 19:16:27 +00:00

changelog: v0.6.225 (#602)

Cordy referenced this issue

2026-09-18 19:17:13 +00:00

#602: clear stale search text on route/folder change (fix A) #624

Cordy referenced this issue from a commit

2026-09-18 19:20:32 +00:00

Merge pull request '#602: clear stale search text on route/folder change (fix A)' (#624) from fix-602 into main

Cordy commented

2026-09-18 19:27:14 +00:00

Author

Owner

Shipped in v0.6.225 (PR #624, tag on 4a400c3), live on both dogfoods — fix A as picked.

Search is per-view now: any route or folder change clears the searchbox (and bumps searchSeq + cancels the debounce, so an in-flight header search can't land on the new view either). The one deliberate exception: a same-path reload — the refresh load(cwd) after rename/delete/upload — keeps your active filter, which is what the end-of-load() filter reapply was originally for. Leaving the dedicated "Results for…" view always clears.

Decision logic is the pure:search-reset block with a node test covering all four cases (folder change, route change, same-path refresh, leaving search view). Repro from the report: type text → Shares → open a shared folder → the folder now lists normally with an honest footer.

Shipped in **v0.6.225** (PR #624, tag on 4a400c3), live on both dogfoods — fix A as picked. Search is per-view now: any route or folder change clears the searchbox (and bumps `searchSeq` + cancels the debounce, so an in-flight header search can't land on the new view either). The one deliberate exception: a **same-path reload** — the refresh `load(cwd)` after rename/delete/upload — keeps your active filter, which is what the end-of-`load()` filter reapply was originally for. Leaving the dedicated "Results for…" view always clears. Decision logic is the `pure:search-reset` block with a node test covering all four cases (folder change, route change, same-path refresh, leaving search view). Repro from the report: type text → Shares → open a shared folder → the folder now lists normally with an honest footer.

Cordy closed this issue

2026-09-18 19:27:20 +00:00

Cordy referenced this issue

2026-09-18 19:37:59 +00:00

Browser password manager fills the saved local-login username into the SPA searchbox #625

Cordy referenced this issue

2026-09-18 19:41:03 +00:00

#625: keep the password manager out of the searchbox #626