mirror of
https://github.com/microsoft/microsoft-ui-xaml.git
synced 2026-10-28 08:25:50 +08:00
ayushjai19
c0587a63bf
## Fixes Fixes #9789 ## PR Type - [x] Bugfix ## Description In `Minimal` display mode (`PaneDisplayMode="LeftMinimal"`, or `Auto` in a narrow window), `HeaderContent` uses the theme margin `NavigationViewMinimalHeaderMargin = -24,44,0,0`. The negative left value is designed to pull the header back into the button slot that `ContentLeftPadding` reserves for the pane toggle, back, or close button: 40px - 24px = a 16px inset. `UpdateBackAndCloseButtonsVisibility()` sizes `ContentLeftPadding` from the buttons that are actually visible. When the back button, the close button, *and* the pane toggle button are all hidden, the padding is 0, so the header lands at x = -24 and gets clipped. ### Current Behavior With `PaneDisplayMode="LeftMinimal"`, `IsBackButtonVisible="Collapsed"` and `IsPaneToggleButtonVisible="False"`, the header is shifted 24px past the left edge and its first characters are cut off. If either button is shown, the header looks right. ### New Behavior When the control is in Minimal mode and no back, close or pane toggle button is visible, `ContentLeftPadding` keeps one pane-toggle-button slot (`PaneToggleButtonWidth`, 40px by default). The header then has the same 16px inset it has when exactly one button is visible. Nothing else changes: when any button is visible the padding is identical to before, and non-Minimal modes don't use this padding at all. ```cpp if (useLeftPaddingForBackOrCloseButton && leftPaddingForBackOrCloseButton == 0.0) { leftPaddingForBackOrCloseButton = GetPaneToggleButtonWidth(); } ``` `UpdateBackAndCloseButtonsVisibility()` now also runs after a runtime change of `PaneDisplayMode` (so LeftMinimal→Top clears the slot) and of `CompactModeThresholdWidth`/`ExpandedModeThresholdWidth` (in `Auto` these can flip `DisplayMode` between Minimal and Compact/Expanded without a resize). Before this, the SplitView `DisplayMode` callback refreshed the padding while `DisplayMode` still held the *old* value, so the padding went stale: 40px kept in Compact, or the clipped 0 back in Minimal. Every other path that changes the display mode (resize, `OnApplyTemplate`, `IsBackButtonVisible`, `IsPaneToggleButtonVisible`, `IsPaneOpen`) already refreshed it. ## Customer Impact User-facing. Apps that hide both NavigationView buttons in LeftMinimal (or Auto when narrow) now see their whole header instead of a clipped one. ## Regression Potential - [x] Low risk: 7 lines in one function (only the "Minimal + no buttons visible" case changes), plus two one-line refresh calls on property changes that re-run the existing padding computation. Modes checked: Left, LeftCompact, Top and Auto (wide) don't use `ContentLeftPadding` (`useLeftPaddingForBackOrCloseButton` is false), so they're unchanged. LeftMinimal and Auto (narrow) change only when no button is visible. Pane open (close button shown) is unchanged. RTL mirrors the Grid column, so it's fine. Possible visible difference: an app that overrides `NavigationViewMinimalHeaderMargin` with a non-negative left value **and** hides both buttons will see its header move 40px right. That's the same offset those apps already get when one button is visible. Overlap with open PR #12258 (#5306): no conflict. That PR doesn't touch `NavigationView.cpp`, and its test asserts `ContentLeftPadding == 80` with both buttons visible, a path this PR doesn't change. Both PRs add tests to `NavigationViewTests.cs`, but in different places. ## How Has This Been Tested? - [x] I have performed a self-review of my own code - [x] I have added tests to cover my changes: `NavigationViewTests.VerifyHeaderIsNotClippedInLeftMinimalWhenBackAndPaneToggleButtonsAreHidden`. It measures `HeaderContent`'s left offset with only the toggle button visible and again with no buttons, then checks that the second offset is ≥ 0 and equal to the first. - [x] Existing tests pass (run on a test VM, x64chk; see the results below) Results: - **Red** (test-only commit `0fcb1e91f`): the new test fails with `IsGreaterThanOrEqual(-24, 0)` / `AreEqual(16, -24)`. The header is at x=-24 with no buttons and at x=16 with one button. - **Green** (fix commit `85060bb04`): the new test passes (1/1). - **Regression sweep** `*NavigationViewTests*` (API + Interaction) on the fix commit: 121 passed, 58 failed, 1 skipped. The same sweep on `origin/main` `866ba81a1`: 36 passed, 142 failed, 1 skipped. **Every one of the 58 failures also fails on `origin/main`, so there are 0 regressions.** The 5 API failures (`VerifyHeaderContentMarginOn{Minimal,Top}Nav`, `VerifyPaneDisplayModeAndDisplayModeMapping`, `VerifyVisualTree_{Old,Optimized}Styles`) are pre-existing visual-tree `RenderSize`/OS-version diffs on this VM. The Interaction-test failures are environmental and flaky there. Review follow-ups (full builds, Oct 19; compared with a shared `origin/main` `866ba81a1` baseline run on the same VM): - `VerifyHeaderPaddingUpdatesWhenSwitchingBetweenLeftMinimalAndTop` (with `2ad8d8434`): passes. - `VerifyHeaderPaddingUpdatesWhenCompactModeThresholdWidthChangesDisplayMode`: **red** on test-only `2b9aa04ed` (`AreEqual(0, 40)` in Compact, `AreEqual(40, 0)` back in Minimal), **green** on fix `e6d44591f`. - Sweep on `e6d44591f`: `*ApiTests.NavigationViewTests*` 39/44, where the 5 failures are the same 5 pre-existing failures as on main. `*NavigationViewTests.PaneBehaviorTests*` 33/34, where the 1 failure (`SelectingAnItemInLeftCompactOrLeftMinimalClosesPane`) also fails on main. **0 regressions.** ## Screenshots (if appropriate) After fix: <img width="899" height="604" alt="image" src="https://github.com/user-attachments/assets/04494ae2-cef3-4875-b30b-6b91eb1c0872" /> <img width="881" height="587" alt="image" src="https://github.com/user-attachments/assets/85907aad-1abf-47fe-9f2f-5b49164515ce" />
WinUI
About WinUI · Documentation · Release notes
WinUI is a user interface layer that contains modern controls and styles for building Windows apps. The current generation is WinUI 3, which ships as part of the Windows App SDK.
- Modern UI: WinUI embodies Fluent Design to enable intuitive, accessible, and powerful experiences and the latest user interface patterns.
- Developers in control: Use .NET with C# or C++ to write apps that run great on x86, x64 and ARM.
- Optimized for modern experiences & hardware: Create performant experiences with WinUI that are optimized for modern hardware.
- Part of the Windows App SDK: The Windows App SDK is a set of libraries, frameworks, components, and tools that you can use in your apps to access powerful Windows platform functionality from all kinds of apps on many versions of Windows. The Windows App SDK combines the powers of Win32 native applications alongside modern API usage techniques, so your apps light up everywhere your users are.
- Powers key experiences in Windows: Windows experiences and apps are built with WinUI. Its rich control set and styles make it easy to develop high-quality experiences used by millions every day.
📋 Getting started with WinUI
For WinUI, your app's users must be on Windows 10 1809 - Build 17763 or newer (including Windows Insider Previews).
The full documentation of WinUI can be found on Microsoft Learn:
- Get started with WinUI
- Build your first WinUI app
- Migrate from UWP to the Windows App SDK
- Windows Runtime APIs not supported in desktop apps
- WinUI & Windows App SDK samples
🖼️ WinUI 3 Gallery
Make sure to also check out the WinUI 3 Gallery, our interactive sample experience showing everything you can do with WinUI.
📺 WinUI Community Call
The WinUI Community Call is your opportunity to learn about WinUI and to engage with the WinUI team and community. Join us online on YouTube at the Windows Developer channel.
📢 Contributing to WinUI
The WinUI team welcomes your feedback! To understand how we handle incoming feature requests and bugs, please see our contribution handling guidelines.
For information on how to contribute, please see Contributing to WinUI.
Warning
We're not yet ready to accept code contributions, but we are working towards that goal. It is now possible to build the WinUI product binaries, with work in progress to share test code and enabling locally running tests. To get started building WinUI from source and see more details on current limitations, see Getting started with building WinUI. See the WinUI OSS Update post to check the latest status.
For the latest code and updates, use the
mainbranch.
🛣️ Roadmap
For info on the WinUI release schedule and high level plans please see the WinUI roadmap.
🔧 WinUI for UWP
WinUI for UWP (WinUI 2) is a library of controls that provides Microsoft UI controls and features for UWP apps. Learn more about WinUI for UWP here or download the source code here.
You can get the WinUI 2 Gallery on the Microsoft Store and see the source code here.
Data/Telemetry
This project collects usage data and sends it to Microsoft to help improve our products and services. Note, however, that no data collection is performed when using your private builds.
Code of Conduct
This project has adopted the Microsoft Open Source Code of Conduct.
For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.