Skip to content
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

Merged
merged 10 commits into from
May 21, 2021

Conversation

dreddy-work
Copy link
Member

@dreddy-work dreddy-work commented Apr 15, 2021

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

…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.
@dreddy-work dreddy-work requested a review from a team as a code owner April 15, 2021 21:11
@ghost ghost assigned dreddy-work Apr 15, 2021
@dreddy-work dreddy-work added the area-HDPI-SA Issues related to high DPI SystemAware mode label Apr 15, 2021
@RussKie RussKie added the 🚫 * NO-MERGE * The PR is not ready for merge yet (see discussion for detailed reasons) label Apr 19, 2021
@RussKie RussKie changed the title [Do not merge] Fix regression in ParkHandle method from .NET framework Fix regression in ParkHandle method from .NET framework Apr 19, 2021
@RussKie RussKie marked this pull request as draft April 19, 2021 12:10
@dreddy-work dreddy-work marked this pull request as ready for review May 19, 2021 16:13
@dreddy-work dreddy-work removed the 🚫 * NO-MERGE * The PR is not ready for merge yet (see discussion for detailed reasons) label May 19, 2021
Copy link
Member

@RussKie RussKie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A little more work needed.

Please rebase instead of tracking-merges
image

@ghost ghost added 📭 waiting-author-feedback The team requires more information from the author and removed 📭 waiting-author-feedback The team requires more information from the author labels May 19, 2021
@dreddy-work dreddy-work requested a review from RussKie May 20, 2021 00:30
@RussKie RussKie added the 📭 waiting-author-feedback The team requires more information from the author label May 20, 2021
@ghost ghost removed the 📭 waiting-author-feedback The team requires more information from the author label May 20, 2021
@RussKie RussKie added the 📭 waiting-author-feedback The team requires more information from the author label May 20, 2021
@dreddy-work
Copy link
Member Author

Tests are failing random but there is a genuine issue. Will be investigating.

@ghost ghost removed the 📭 waiting-author-feedback The team requires more information from the author label May 20, 2021
@RussKie
Copy link
Member

RussKie commented May 20, 2021

    System.Windows.Forms.Tests.AccessibleObjects.ErrorProviderAccessibleObjectTests.ErrorProvider_NameDoesntEqualControlTypeOrChildName [FAIL]
      System.ComponentModel.Win32Exception : Failed to set Win32 parent window of the Control.
      Stack Trace:
        /_/src/System.Windows.Forms/src/System/Windows/Forms/Control.cs(10810,0): at System.Windows.Forms.Control.SetParentHandle(IntPtr value)
        /_/src/System.Windows.Forms/src/System/Windows/Forms/Control.ControlCollection.cs(121,0): at System.Windows.Forms.Control.ControlCollection.Add(Control value)
        /_/src/System.Windows.Forms/src/System/Windows/Forms/Form.ControlCollection.cs(58,0): at System.Windows.Forms.Form.ControlCollection.Add(Control value)
        /_/src/System.Windows.Forms/tests/UnitTests/AccessibleObjects/ErrorProviderAccessibleObjectTests.cs(36,0): at System.Windows.Forms.Tests.AccessibleObjects.ErrorProviderAccessibleObjectTests..ctor()
           at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean wrapExceptions) in System.Private.CoreLib.dll:token 0x6000644+0x66

…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.
@dreddy-work
Copy link
Member Author

dreddy-work commented May 20, 2021

Tests are failing random but there is a genuine issue. Will be investigating.

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.

RussKie
RussKie previously approved these changes May 20, 2021
Copy link
Member

@Tanya-Solyanik Tanya-Solyanik left a 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?

@dreddy-work
Copy link
Member Author

dreddy-work commented May 21, 2021

What makes you say that the change is risky? It looks like a direct port from the FX, no?

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.

@dreddy-work
Copy link
Member Author

Could yo please explain what the tests are doing?

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.

@dreddy-work
Copy link
Member Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@dreddy-work dreddy-work merged commit 137b968 into main May 21, 2021
@ghost ghost added this to the 6.0 Preview6 milestone May 21, 2021
@dreddy-work dreddy-work deleted the dev/dreddy/FixParkingWindowRegression branch May 21, 2021 17:10
Copy link
Member

@Tanya-Solyanik Tanya-Solyanik left a 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));
Copy link
Member

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()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: ParkingWindow_PerMonitorV2

@dreddy-work
Copy link
Member Author

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.

Tested. It does set to the context passed.

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.

Agree as our process is already running in UNAWARE and unaware parking window might have already been there.

@RussKie
Copy link
Member

RussKie commented May 23, 2021

Tests that alter/affect global singletons (e.g. Application) must be done as MAUI tests or run under RemoteExecutor (subject to dotnet/arcade#7426)

@ghost ghost locked as resolved and limited conversation to collaborators Jan 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-HDPI-SA Issues related to high DPI SystemAware mode
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants