You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes
Is this bug related specifically to tooling in Visual Studio (e.g. XAML Designer, Code editing, etc...)? no
Problem description:
The code that simulates user input to move the mouse sometimes ends up one pixel away from the intended position. This surely has to do with the translation to virtual desktop coordinates. It works fine when only one monitor is attached, but not in multi-monitor. Well, at least not in my configuration: 2160x3840 (200%) and 3440x1440 (100%):
This is not urgent, as our standard testing is done on single-monitor machines. But it will need to be fixed before making the tests public, as contributors will surely run tests in multi-monitor, and will get false failures.
Note: There are at least two copies of this code in the test repo - one used by DRTs, another by feature tests.
Actual behavior:
Mouse sometimes ends up one pixel away from the intended position. It depends on the position, and how the actual pixels align with the virtual-desktop coordinates. Thus the test results can be different on repeated attempts, depending on where the OS chooses to display the test's main window.
Expected behavior:
Mouse moves to the intended position.
Minimal repro:
DrtWindowResizeGripFlowDirection
"Did not get correct Height after changing FlowDirection and resizing through ResizeGrip. expected:350 -- actual:351"
(The mouse drag to resize the window ended one pixel below the intended.)
DrtControls -suite Menu.Capture
" ASSERT failed [Suite: Menu.Capture Test: CaptureTest] AutoClose popup should be open"
(Test intended to move the mouse to the top-left of an open popup, and click to close a nested ComboBox and restore capture to the popup. Instead the mouse moved just off the popup, and the click closed the popup.)
Presumably many more false failures in feature tests.
The text was updated successfully, but these errors were encountered:
Problem description:
The code that simulates user input to move the mouse sometimes ends up one pixel away from the intended position. This surely has to do with the translation to virtual desktop coordinates. It works fine when only one monitor is attached, but not in multi-monitor. Well, at least not in my configuration: 2160x3840 (200%) and 3440x1440 (100%):
This is not urgent, as our standard testing is done on single-monitor machines. But it will need to be fixed before making the tests public, as contributors will surely run tests in multi-monitor, and will get false failures.
Note: There are at least two copies of this code in the test repo - one used by DRTs, another by feature tests.
Actual behavior:
Mouse sometimes ends up one pixel away from the intended position. It depends on the position, and how the actual pixels align with the virtual-desktop coordinates. Thus the test results can be different on repeated attempts, depending on where the OS chooses to display the test's main window.
Expected behavior:
Mouse moves to the intended position.
Minimal repro:
DrtWindowResizeGripFlowDirection
"Did not get correct Height after changing FlowDirection and resizing through ResizeGrip. expected:350 -- actual:351"
(The mouse drag to resize the window ended one pixel below the intended.)
DrtControls -suite Menu.Capture
" ASSERT failed [Suite: Menu.Capture Test: CaptureTest] AutoClose popup should be open"
(Test intended to move the mouse to the top-left of an open popup, and click to close a nested ComboBox and restore capture to the popup. Instead the mouse moved just off the popup, and the click closed the popup.)
Presumably many more false failures in feature tests.
The text was updated successfully, but these errors were encountered: