Synchronize headless UI tests on idle and hit-tested clicks - #4083
Merged
Merged
Conversation
Right_Clicking_A_Second_Row_Moves_The_Context_Highlight_To_It still timed out on the Windows Debug CI job, now in the hit-test wait added for the second right-click: for the full 60s no hit at the precomputed point matched the captured row container. A light-dismiss overlay that survives one frame cannot explain that many rendered frames; a container that is no longer the one on screen can. The test only waits for three assemblies, so the rest of the list keeps loading on the slow agent while the test runs, and every insertion reshuffles the rows - re-realising containers and moving them - after the row and point were captured. The wait now resolves the row container and the click point on every poll and matches the hit by node instead of by container identity, and a timeout reports the point and what was hit instead so a further failure is diagnosable from the log. Assisted-by: Claude:claude-fable-5:Claude Code
The headless UI tests synchronized with the application by pumping a fixed number of frames (39 loops of RunJobs/Delay across 19 files) and by pressing at a point computed once from a control's bounds. Both encode how fast the machine that wrote the test was: on the loaded Windows Debug CI agent the frame count comes up short and the point goes stale, which is the recurring timeout in the tree context-menu tests and the reason each such failure was repaired one test at a time. Waiters.WaitForIdleAsync replaces the frame loops. It observes the actual precondition - no dispatcher job queued at Background priority or above, no assembly still loading in the background sweep, a frame rendered - and requires it on two consecutive polls so a thread-pool continuation about to post back is caught as well. Window.ClickAsync replaces element-targeted MouseDown/MouseUp pairs. It re-resolves the target on every poll and presses only once the window's hit test at the click point answers with that target, reporting the point and what was hit instead on timeout. That diagnostic exposed one vacuous test: User_Click_On_Visible_Row_Does_Not_Recentre_Viewport clicked the centre of a row wider than the tree viewport, which lies under the decompiler text view, so its assertion held without the row ever being clicked. It now clamps the point to the viewport like the other tree-row clicks. Clicks at text positions and press-only gutter clicks stay raw; they do not target an element. Assisted-by: Claude:claude-fable-5:Claude Code
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
1 participant
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.
Stacked on #4082 (its commit is included here until it merges).
The headless UI tests synchronized with the app by pumping a fixed number of frames (39
RunJobs/Delayloops across 19 files) and by pressing at a point computed once from a control's bounds. Both encode how fast the authoring machine was; on the loaded Windows Debug agent the frame count comes up short and the point goes stale, which is the recurring timeout behind the tree context-menu failures (#4080's run, 170aea4, #4082) that were being repaired one test at a time.Waiters.WaitForIdleAsync()replaces the frame loops: no dispatcher job at Background priority or above, no assembly still loading in the background sweep, a frame rendered, on two consecutive polls.Window.ClickAsync(resolveTarget, button, ...)replaces element-targetedMouseDown/MouseUppairs: re-resolves the target on every poll, presses only once the window's hit test at the click point answers with that target, and reports point + hit visual on timeout.That diagnostic exposed one vacuous test:
User_Click_On_Visible_Row_Does_Not_Recentre_Viewportclicked the centre of a row wider than the tree viewport, which lies under the decompiler text view, so the assertion held without the row ever being clicked. It now clamps to the viewport like the other tree-row clicks and still passes.Clicks at text positions and press-only gutter clicks stay raw; they do not target an element.
Full
ILSpy.Tests(Debug, Linux): 1243 passed / 0 failed, three runs.This PR was written by an AI agent (Claude Code) under the author's supervision.