Wait for workspace detail children to lay out before asserting bounds - #441
Merged
Merged
Conversation
PR #440 widened the workspace chrome mount loop, but its break condition tests only that the eight children are non-null. The assertion immediately afterwards tests something stronger -- that four of them have non-empty BoundingRectangle -- so the loop can exit the instant the children appear in the UIA tree, before the loop panel has laid them out. Wait for the layout to settle on exactly the condition being asserted. All 378 Require predicates remain byte-identical to main. Refs #438 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Signed-off-by: Colin Neilens <coneilen@microsoft.com>
This was referenced Sep 24, 2026
coneilen
added a commit
that referenced
this pull request
Sep 24, 2026
The settle loop added in #441 polled cached AutomationElement references. These children are served by a custom fragment provider that destroys and recreates them when the loop panel re-lays out, and a dead fragment reports an empty AutomationId and empty BoundingRectangle instead of throwing, so a cached reference can never recover from a remount. The loop burned its whole budget and then failed with a blank id in the message. Re-resolve the four children from the live tree on every attempt and require one observed generation to satisfy existence and layout together, then rebind the variables so the later Invoke cannot run against a stale fragment. Signed-off-by: Colin Neilens <coneilen@microsoft.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
This was referenced Sep 24, 2026
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.
Summary
Follow-up to #440, fixing a gap in that PR rather than a new defect elsewhere.
#440 widened the workspace chrome mount loop to 20s, but its break condition tests only that the eight chrome children are non-null:
The assertion immediately afterwards tests something strictly stronger — that four of those children have a non-empty
BoundingRectangle. A UIA element can be present in the tree before the loop panel has laid it out, so the loop can exit the instant the children appear and the assertion then reads zero-sized bounds.Widening the mount budget could never fix this, because the loop was never waiting on the right condition.
This adds a bounded 10s wait on exactly the condition the assertion checks, immediately before it.
No assertion is weakened. All 378
Requirepredicates are byte-identical tomain, verified by extracting and diffing the predicate lines. Theforeachstill asserts on all four children with the same message.Evidence
RED: PR #439's
windows-shellon rebased head868a002->workspace right panel child ... has empty bounds, a third distinct failure site in this one block, after #440 had already fixed the other two (omitted the toolbar identity childanddid not expose expand control after collapse)GREEN: this branch's
windows-shelljob exercises the same block on the same loaded runner -> expected to pass, with the CI result on this PR as the evidence, since that runner is the only environment that reproduces the layout timingREGRESSION:
[System.Management.Automation.Language.Parser]::ParseFileon the edited gate -> PARSE OK, and extracting everyRequireline frommainand from this branch and comparing -> 378 vs 378, all byte-identical, confirming no predicate was weakenedNote
Three distinct failure sites have now surfaced in this single block across four CI runs, each a different flavour of asserting before the UI settled. This is the #438 sleep-before-assert class; the general fix is to wait on the asserted condition rather than on a proxy for it.