Skip to content

fix(media): let the upload queue window stay closed mid-upload - #659

Open
mostafasadeghidev wants to merge 1 commit into
CoreBunch:mainfrom
mostafasadeghidev:fix/media-upload-queue-stays-closed
Open

mostafasadeghidev wants to merge 1 commit into
CoreBunch:mainfrom
mostafasadeghidev:fix/media-upload-queue-stays-closed

Conversation

@mostafasadeghidev

Copy link
Copy Markdown
Contributor

Split out of #501, per review: the upload-queue fix alone, on main.

The bug

While files were uploading, the upload queue window could not be closed. The close button worked and an effect undid it: it depended on both uploadQueue.active and the open state, so closing re-ran it, active && !open was true, and the window reopened on the next commit.

The fix

The open state moves into useUploadQueueWindow(active). It opens the window on the transition into an active upload — detected during render against the last active it saw, the "adjust state when a prop changes" pattern — and on nothing else.

  • Closing hides the transfer; it does not cancel it.
  • The next upload opens the window again.
  • A finished transfer still leaves it open until dismissed, as before.

Doing it in render also drops the set-state-in-effect disable and the one-commit open lag.

Not included: the toolbar progress label (Uploads 3/5) and the new default position from #501. The first is a separate change that I can open on its own if you want it; I dropped the second.

Tests

uploadQueueWindow.test.tsx drives the real hook with renderHook through what a user does: an upload starts, they close the window, progress re-renders the page. With the old effect swapped back in, "stays closed after the user closes it mid-upload" fails.

Verification

bunx tsc -b                         clean
bunx eslint src/admin/pages/media   clean
bun test src/__tests__/media        all pass

Docs: the UploadQueueWindow row in docs/features/media.md.

The close button worked, then an effect undid it. The effect depended on
both `uploadQueue.active` and the window's open state, so closing the
window re-ran it, `active && !open` was true, and it opened again on the
next commit. While a transfer was in flight the window could not be shut.

The open state moves into `useUploadQueueWindow(active)`, which opens the
window on the transition into an active upload — detected during render
against the last `active` it saw — and on nothing else. Closing hides the
transfer; it doesn't cancel it. The next upload opens the window again,
and a finished transfer still leaves it open until dismissed. Doing it in
render rather than an effect also drops the set-state-in-effect disable
and the one-commit open lag.

The test drives the real hook through what a user does — upload starts,
close, progress re-renders — and fails against the old effect.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
mostafasadeghidev added a commit to mostafasadeghidev/Instatic that referenced this pull request Oct 16, 2026
CoreBunch#659 is the upload-queue fix split out of CoreBunch#501, rewritten per review:
`useUploadQueueWindow(active)` opens the window on the transition into an
active upload, detected during render, instead of the effect the stack
carried from CoreBunch#501. Same behaviour, no set-state-in-effect disable, and a
test that drives the real hook. The stack's progress label on the toolbar
button (CoreBunch#501, not part of CoreBunch#659) stays, with its tests.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
mostafasadeghidev added a commit to mostafasadeghidev/Instatic that referenced this pull request Oct 16, 2026
…ch#501 is now three PRs

CoreBunch#335 and CoreBunch#499 move to the landed table (shipped in v0.0.21). CoreBunch#501 was
closed in review and asked to come back split: its rows become CoreBunch#658
(select-all), CoreBunch#659 (upload queue stays closed) and CoreBunch#660 (minimize). The
three parts of CoreBunch#501 that are in none of them — the Uploads progress label,
the queue's bottom-left default, and the Dialog body size — are listed as
carried-but-not-proposed, so the README still says what a server runs.

Also: what an installation needs before moving to plain upstream, since
upstream's 031 repeats an ALTER this branch ran as 025.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant