---

This section details on the original issue you should resolve

<issue_title>"Discard Changes" Only Runs if Window is Active</issue_title>
<issue_description>### The problem

Since I'm working in angular, I always have tons of build artifacts to discard which takes a minute or two (also seems to be getting slower lately). As such, I used to start the discard process, then switch to another window and do something else, then it would be done when I returned. Recently it's changed so that it won't complete the process unless I remain in the GitHub Desktop window until it's finished.

UPDATE
I recently tried with a much smaller number of files, and it finished while I was in another window. Either the problem is dependent on the number/size of files being discarded, and/or it's just that the process is taking so long that it seems like the only way to complete it is to have the window open.

Release version

Version 3.5.5 (x64)

Operating system

Windows 11

Steps to reproduce the behavior

1. Highlight files in the changes tab
2. Right click → discard changes
3. Switch to another window for a while
4. Return to GitHub Desktop and see that the discard process is still running
5. Remain in the window and it will finish (eventually..)

Log files

2026-02-26.desktop.production.log

Screenshots

Additional context

In this project, build artifacts are intentionally tracked in Git due to deployment requirements. They cannot be added to .gitignore, as automated deployment scripts rely on committing these artifacts. Therefore, ignoring the build output is not a viable workaround.</issue_description>

Comments on the Issue (you are @copilot in this section)

@niik This is almost certainly due to our queuing logic using `requestAnimationFrame`. I thought we had disabled energy saving functions (such as stopping animations on blur) but I may be mistaken

desktop/app/src/lib/queue-work.ts

Lines 25 to 33 in 1775cae

	export async function queueWorkHigh<T>(
	items: Iterable<T>,
	worker: (item: T) => Promise<any> | any
	) {
	const iterator = items[Symbol.iterator]()
	let next = iterator.next()
	while (!next.done) {
	const start = await awaitAnimationFrame()

Seems like we should probably switch this to using setImmediate instead but before we do so we should investigate whether we even need the work queue any more. I recall adding the work queue because moving to trash on Windows was synchronous and blocked the render loop. I would be surprised if that's still the case.</comment_new>
<comment_new>@niik
Yeah, as I suspected, trashItem is asynchronous now. When the work queue was written it used the moveItemToTrash API which was synchronous. We can just get rid of the queueWorkHigh method and call trashItem directly.</comment_new>