-
Notifications
You must be signed in to change notification settings - Fork 991
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix regression in ParkHandle method from .NET framework #4796
Conversation
…ramework. Without these changes, on PMv2 applications, We might be ending up with wrong Dpiawareness than the requested for windows and some times, might endup failing to parent because of inconsitance DpIcontexts. #2262 addressed for catching the failure but still applications may be still creating wrong DPIawareness windows.
…eddy/FixParkingWindowRegression
…eddy/FixParkingWindowRegression
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
src/System.Windows.Forms/tests/UnitTests/HDPI/ParkingWindowTests.cs
Outdated
Show resolved
Hide resolved
src/System.Windows.Forms/tests/UnitTests/HDPI/ParkingWindowTests.cs
Outdated
Show resolved
Hide resolved
src/System.Windows.Forms/tests/UnitTests/HDPI/ParkingWindowTests.cs
Outdated
Show resolved
Hide resolved
src/System.Windows.Forms/tests/UnitTests/HDPI/ParkingWindowTests.cs
Outdated
Show resolved
Hide resolved
src/System.Windows.Forms/tests/UnitTests/HDPI/ParkingWindowTests.cs
Outdated
Show resolved
Hide resolved
src/System.Windows.Forms/tests/UnitTests/HDPI/ParkingWindowTests.cs
Outdated
Show resolved
Hide resolved
src/System.Windows.Forms/tests/UnitTests/HDPI/ParkingWindowTests.cs
Outdated
Show resolved
Hide resolved
src/System.Windows.Forms/tests/UnitTests/HDPI/ParkingWindowTests.cs
Outdated
Show resolved
Hide resolved
src/System.Windows.Forms/tests/UnitTests/HDPI/ParkingWindowTests.cs
Outdated
Show resolved
Hide resolved
Tests are failing random but there is a genuine issue. Will be investigating. |
|
…n CI build and that too after adding new tests that were setting processwide dpi awareness, I am guessing filaure is because of incorrect DPIawareness between the threads while running tests. Replacing process wide DPI awareness with thread.
Given that these failures are reproduced only in PR build and that too after adding new tests for Parkingwindow that were setting process wide dpi awareness, I am guessing failure is because of incorrect DPI awareness of the threads within the test case execution. Replacing process wide DPI awareness with thread and resetting back after finishing the test. This helped resolve test issue. This change is critical for control/handle creation and impact all DPI awareness modes. This is high risk change and would need to be validated thoroughly in this preview. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The port itself looks good.
What makes you say that the change is risky? It looks like a direct port from the FX, no?
Could yo please explain what the tests are doing?
...em.Windows.Forms/tests/UnitTests/HDPI/System/Windows/Forms/Application.ParkingWindowTests.cs
Outdated
Show resolved
Hide resolved
...em.Windows.Forms/tests/UnitTests/HDPI/System/Windows/Forms/Application.ParkingWindowTests.cs
Outdated
Show resolved
Hide resolved
...em.Windows.Forms/tests/UnitTests/HDPI/System/Windows/Forms/Application.ParkingWindowTests.cs
Outdated
Show resolved
Hide resolved
...em.Windows.Forms/tests/UnitTests/HDPI/System/Windows/Forms/Application.ParkingWindowTests.cs
Outdated
Show resolved
Hide resolved
...em.Windows.Forms/tests/UnitTests/HDPI/System/Windows/Forms/Application.ParkingWindowTests.cs
Outdated
Show resolved
Hide resolved
It is risky because it was impacting all applications irrespective of DPI mode. Yes it does match with Framework but PMV2 mode usage in framework should be very less comparatively. |
Tests were intended to validate that we indeed creating parking windows with expected DPI awareness on them. Setting the scope for control creation and expect the parking handle creation in same DPI awareness when control Handle is created. |
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I seem to remember that SetThreadDpiAwarenessContext is a no-op in a SA or unaware process as well, had you tested that this API works better than scope does.
Tests were intended to validate that we indeed creating parking windows with expected DPI awareness on them. Setting the scope for control creation and expect the parking handle creation in same DPI awareness when control Handle is created.
I don't think that each fact is a new Application, so parking windows created in any other test would persist through the test run, so you are not necessarily verifying creation of this window. These tests verify that appropriate parking window gets associates with each context. I think the first 2 tests can be merged into theory.
its restoring to original value before we set to PMV2. API returns the value it is replacing
I see it now, :) I missed it the first time.
Assert.NotNull(parkingWindow); | ||
|
||
IntPtr dpiContext = User32.GetWindowDpiAwarenessContext(parkingWindow.Handle); | ||
Assert.True(User32.AreDpiAwarenessContextsEqual(User32.DPI_AWARENESS_CONTEXT.UNAWARE, dpiContext)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AssertExtention that compares DPI awareness contexts would be helpful here and in the future. You can factor out this line into a helper method.
} | ||
|
||
[WinFormsFact] | ||
public void ParkingWindow_PermonitorV2() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: ParkingWindow_PerMonitorV2
Tested. It does set to the context passed.
Agree as our process is already running in UNAWARE and unaware parking window might have already been there. |
Tests that alter/affect global singletons (e.g. |
Seems this changes was missed from Day 1 and a regression from .NET Framework.
Ex: https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/Control.cs,8435
Without these changes, on PMv2 applications, We might be ending up with wrong DpiAwareness than the requested for windows being created and some times, might end up failing to parent because of inconsistence DpiAwareness between parent and child.
#2262 addressed for catching the failure in 'SetParent' but applications may be still creating windows with incorrect DpiAwareness.
Need to check on how to add a Unit test.
Microsoft Reviewers: Open in CodeFlow