-
Notifications
You must be signed in to change notification settings - Fork 671
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
NavigationView: Fix content clipping regression #2717
NavigationView: Fix content clipping regression #2717
Conversation
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Hmmm...the two failing tests in Azure Pipelines work fine for me locally and looking at their test code I also can't see anything which would make them fail based on my additions in this PR. I'm also up-to-date with the master branch except for PR c5fa8a6 which does not touch the NavigationView. The two failing tests in question failed already a few days ago too when we first ran Azure Pipelines on this PR. Thoughts? |
The tests are only failing on RS2 with the following errors: NavigationViewTests.SelectionTests.MenuItemAutomationSelectionTest: |
Sorry this info isn't available to you, the Azure Dev Ops team says they are looking at the issue. |
@Felix-Dev the Azure Dev Ops issue has been resolved, you should now be able to see the test failures yourself. |
@StephenLPeters I am looking at the tests in question and I cannot notice anything here why my additional test code added to the test UI would cause these tests to fail.
I took a look at the line and this is the failing code: microsoft-ui-xaml/dev/NavigationView/NavigationView_InteractionTests/SelectionTests.cs Line 141 in 3834f4d
The error above says "IsTrue". How am I supposed to read that? Does it mean And again, I don't have an idea right now why my addition of another NavigationViewItem as the new last one of the NavigationViewItems would cause this tests to fail here. The "Apps" and "Games" NavigationViewItems are untouched by me in this PR. Similar story as for the other failing test. I suppose I could cut out my added test code and add it to one of the other many NavigationView test pages in the MUXControlsTestApp, though that would just be me randomly trying to fix failing tests I don't know why they are failing in the first place. How should we proceed here then? |
The test output indicates the verify that failed so in this case it indicates that the Verify.IsTrue(secondItem.HasKeyboardFocus) failed indicating secondItem.HasKeyboardFocus is false. These tests are only failing on RS2, so make sense that they don't fail locally. I haven't had time to look at why that might be the case. |
Seems like we have to wait for someone form the team then to look at the test failures on RS2 more closely as I won't be able to set up an environment here where I could inspect those myself. |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
@Felix-Dev are you still blocked here? |
@StephenLPeters I will hopefully be able to take a final look at this today and move the failing tests to another existing test page for now. I think I will go with the existing "NavigationVew Regression Test" test page as that page will do it (instead of setting up a new test page). Does that sound reasonable to you? |
Awesome! that does sound reasonable. |
Merged with master. |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
@Felix-Dev the change to use lab test frame dimensions locally just got checked in. Could you merge in master and try running the failing tests again? I'm hoping that accounts for the difference in environments that is causing the lab failures |
@StephenLPeters Merged with master. Unfortunately, I couldn't find all of the failing tests again (previous Azure Pipelines build failures say they are no longer available), but thatnks to the comversattion here, at least one failing test in the pipeline but succeeding for me locally was It just fails (and presumably all the other failing tests) because of my addition of two additional NavigationViewItems on the used test page here. If I remove these two items again, Honestly, since the addition of two more NavigationViewItems to the main NavigationView test page (NavigationViewTestPage) appears to create so much "pain" unrelated specifically to this issue, I am considering moving my added interaction test (which also checks the ContentPresenter margin of child menu item) to a different test page, untouched by the majority of the tests. Not yet sure which page (I'll have to take a closer look). |
Does it fail because the test is trying to click a button that is off screen? can we just call invoke instead, or if clicking is important call BringIntoView first? |
Yep, the unrelated test fails because the addition of two more NavigationViewItems pushed the settings button off the screen (prior to the CI frame PR, the settings button still fit into the screen area so it ran fine for me). I can take a look at your suggestion here. |
@StephenLPeters microsoft-ui-xaml/dev/NavigationView/NavigationView_InteractionTests/SelectionTests.cs Line 216 in 647cb4d
I can not call I did not find a private void BringSettingsIntoViewButton_Click(object sender, RoutedEventArgs e)
{
if (VisualTreeUtils.FindElementOfTypeInSubtree<ItemsRepeaterScrollHost>(NavView) is ItemsRepeaterScrollHost scrollHost)
{
scrollHost.ScrollViewer.ChangeView(null, double.MaxValue, null);
}
} Unfortunately, while the Am I missing something here? |
does FrameworkElement.BringIntoView not work? https://docs.microsoft.com/en-us/dotnet/api/system.windows.frameworkelement.bringintoview?view=netcore-3.1 |
@StephenLPeters Unfortunately, that method is currently not available in UWP. |
It is available in UWP: https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.uielement.startbringintoview?view=winrt-19041 Also looks like there are merge conflicts you need to resolve @Felix-Dev . |
StartBringIntoView() != BringIntoView() (it's asynchronous). That threw me a loop yesterday night but it seems that adding a |
Beside the asynchronity BringIntoView and StartBringIntoView should be the same though, and Wait.ForIdle shouldn't care whether it's async or not. But if it works now, that's great. |
@StephenLPeters Merged with master and fixed failing Will look into the other failing tests the pipeline should throw out. |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
@StephenLPeters Fixed remaining failing interaction tests. |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Description
This PR fixes a NavigationView content clipping regression in closed compact mode introduced with WinUI 2.4.
Motivation and Context
Fixes #2541.
How Has This Been Tested?
Added interaction test + visually
Screenshots:
Current cutoff text in closed compact mode excluding this PR:
![image](https://user-images.githubusercontent.com/1398851/83925235-f7055700-a786-11ea-8a95-5b5053c05be2.png)
WinUI 2.3 closed compact look restored with this PR:
![image](https://user-images.githubusercontent.com/1398851/84575046-bcb14080-adaa-11ea-9e34-936cf8869866.png)
(The cutoff NavigationViewItem content is "Menu Item".)