Repository navigation
fix(media): let the upload queue window stay closed mid-upload - #659
Open
mostafasadeghidev wants to merge 1 commit into
Open
mostafasadeghidev wants to merge 1 commit into
mostafasadeghidev wants to merge 1 commit into
Conversation
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.activeand the open state, so closing re-ran it,active && !openwas 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 lastactiveit saw, the "adjust state when a prop changes" pattern — and on nothing else.Doing it in render also drops the
set-state-in-effectdisable 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.tsxdrives the real hook withrenderHookthrough 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
Docs: the
UploadQueueWindowrow indocs/features/media.md.