Stabilize focus handling in HoverTest - #4241
Merged
vogella merged 1 commit intoAug 13, 2026
Merged
Conversation
HoverTest requested focus for the editor exactly once per attempt and then hard-asserted that the text widget owns it. Under a loaded CI machine the window manager can take activation away in that window, so the test failed with "editor does not have focus" even though the retry loop right next to it was meant to cover such hiccups. Focus acquisition moves into a helper that re-activates the window and re-requests focus a few times, and a failure to get focus now continues the existing retry loop instead of aborting the test. The assertion is kept for the case that focus is never obtained, so a genuinely stuck window manager still fails with the same message. See eclipse-platform#1808
Contributor
Test Results 858 files 858 suites 54m 5s ⏱️ Results for commit 494bc90. |
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.
HoverTestrequested focus for the editor exactly once per attempt and then hard-asserted that the text widget owns it. On a loaded CI machine the window manager can take activation away in exactly that window, which is where the recurringeditor does not have focusfailures come from, even though the retry loop right next to the assertion was meant to cover such hiccups.Focus acquisition now lives in a helper that re-activates the window and re-requests focus a few times, and failing to get focus continues the existing retry loop instead of aborting the test. The assertion is kept for the case that focus is never obtained, so a genuinely stuck window manager still fails with the same message rather than being masked. Nothing is added to the happy path: when focus works on the first request the test runs exactly as fast as before.
See #1808.