Repository navigation
test(app): wait for the finished ring to hide the donut before the next drag - #1319
Merged
Merged
Conversation
…xt drag The macOS keyboard test failed now and then with Remembered 1 instead of 2. The fake photo's job can end on a worker before the drop's own dispatcher run is over. Then the ring is already finishing when the test closes the donut, Close leaves the window up for the ring to hide, and the next drag reuses a window that is still active: headless, giving the keyboard back can't make it resign key as it does on a Mac. TakeKeyboard sees an active window and doesn't remember the front app again. The test now waits for the job's end before closing, so every run takes the same path, then for the window to hide. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
DonutFlipTests.On_macos_the_keyboard_goes_back_after_a_conversion_and_stays_for_a_tools_windowfails now and then onportable (macos-15, osx-arm64):Assert.Equal(2, platform.Remembered)gets 1. Seen in runs 42635941264 (main) and 42515220891.Why it fails
It's a race in the test. The product code is fine.
photo.jpg. The headlessDragDrophelper runs the dispatcher once more after the drop. If the worker has already ended the job by then, itsRefreshlands andOnProgressJobChangedputs the ring intoCompleteProgress, which holds for wall-clock time.radial.Close(animate: false)then seesIsFinishingProgressand returns without hiding the window, leaving the ring to hide it later. If the job is still running,Closehands it to the toast and hides the window at once. That path passes.DragOnto→ShowForDrag→LeaveProgressMode()drops the ring's pending hide, so the window never hides and never deactivates. In headless,TakeKeyboard's fallback callswindow.Activate(), butReturnKeyboardhas nothing that undoes it (handle 0, null platform). The window is stillIsActive, soTakeKeyboardreturns early andRememberFrontAppisn't called again.This race came in with the test itself (fe3dd6a, 2026-10-30), together with the
window.IsActiveguard. It wasn't caused by ebadfc7 (PR #1155).Why the product is fine on a real Mac
ReturnKeyboard→ReleaseKeyWindoworders the panel out and back in, so it stops being the key window and Avalonia getsDeactivated. A new drag over a finishing ring therefore finds the panel inactive and takes the keyboard again. TheIsActiveguard only skips the take when Filee's own window really has the keyboard: either while_tookKeyboardis already set, or for a click-mode donut, where Filee is the front app andRememberFrontAppwould record nothing anyway.Reproduction
The branch
repro/donut-keyboard-ring-race(one commit on main) waits for the job's end before the close, which forces the failing path. Aportable.ymlrun on it, with macOS: https://github.com/KnifeLemon/Filee/actions/runs/42663753064 failed on both macOS jobs (arm64 and Intel) with the sameExpected: 2, Actual: 1at theRememberedcheck, and nothing else failed. The repro also assertsIsFinishingProgressjust before the close, and that check passed, so the failing path is the one described above.Fix
Only the test changes. It now waits for the job's end before closing, so every run takes the same path (the one that used to fail). It then pumps the dispatcher and the render timer until the ring hides the window, and asserts that the window is inactive before the second drag.
macOS can only be checked on CI. The test is skipped on Windows.
🤖 Generated with Claude Code