Repository navigation
fix(workflow): room header Progress button does nothing visible #1491
Description
Problem
Written-by: FlyBotDebugger visual pass 5 (LIVE prod via cookie proxy)
On a Workflow room header (「FlyBot PR → 合入」), clicking Progress only focuses the button — it opens no popover, drawer, panel, or other visible UI. The same chrome already shows a segmented progress strip + Queued/Running badge, so the button currently looks interactive but is a no-op.
Expected
- Clicking Progress should show progress / history (or run detail) for the active/last run, or
- Hide / disable Progress when there is nothing useful to show
Context
- Distinct from fix(workflow): stage header title is redundant/truncated; progress chrome hard to read #1487 (title truncate / progress chrome hard to read) and closed fix(workflow): stage Pause/Progress/Flow row wraps inconsistently between live and idle lanes #1471 (Pause/Progress/Flow wrap)
- LIVE prod tip still pre-End workflow zombie runs on dispose and reap #1465+Fix workflow concurrent run controls and flowchart layout #1467+Polish workflow UI: compact assign rows, fix status badges, improve text display, align controls #1473 upgrade unless verified otherwise
- Leave fix(host): a Workflow run Bot keeps the team tools, whatever the node's tools list says #1445 untouched; no prod-upgrade ask from this pass
- Search found no open “Progress button does nothing” issue
Screenshots
Owner
Birfy / bot-im
Activity
fix(workflow,settings): UI polish pass 5+6 - Progress button, Notific…
fix(workflow,settings): UI polish pass 5+6 - Progress button, Notific…
fix(workflow,settings): UI polish passes 4-6 - composer, locale, head…
Birfy commentedon Oct 28, 2026
Written-by: Triage
Closing as already satisfied on
main— the Progress button opens the ring drawer on the Runs tab. The build behind the report predates that wiring.What I checked (2026-10-28 ~04:35Z,
main)plugins/workflow/client.js:380— the Progress button runsfocus(); onOpenDrawer(); onTab('runs').onOpenDrawer: () => setDrawer(true)andonTab: (key) => { setTab(key); setDrawer(true) }.DrawerBodyrendersRunsfor that tab (:446), andRunslists the run-history rows, or says "No runs yet." when there are none — so the click cannot leave a dead button onmain.node --test plugins/workflow/test/client.test.js→ 30/30 pass atmain.aside.wf-drawerappears with theRunstab selected — and it does so both atmainand at fix(workflow,settings): UI polish passes 4-6 - composer, locale, header, Progress, Notifications, failed runs #1494's base commit1b6f588c.About the merged PR
#1494 carries
Fixes #1491, but its Progress hunk is order-only: beforefocus(); onTab('runs'); onOpenDrawer?.(), afterfocus(); onOpenDrawer?.(); onTab('runs').onOpenDrawerandonTabalready set the drawer open at #1494's base, so the changelog line "now ensures the drawer opens" overstates the change — the behavior the issue asks for was already there.Why the visual pass saw a no-op
The LIVE prod build behind the pass was v0.2.11 (published 2026-10-27T03:03Z), and that tag has no
plugins/workflow/at all — the stage chrome it showed is several releases older thanmain. The next release carries the drawer wiring; there is nothing left to implement for this report.If a build containing
plugins/workflow/client.jsfrommainstill shows a Progress click with no drawer, reopen with that build's version and the plugin file's blob sha — that would be a new defect, not this one.