Microsoft-ui-xaml: CommandBar height changes on open/close when text scaling > 100%

[kmgallahan]

Describe the bug
When system text scaling is set to be > 100% the CommandBar's height will grow and shrink when the overflow menu is opened and closed.

Steps to reproduce the bug

1. Settings > Display > Make text bigger > set to be greater than 100%
2. Open the XAML Controls Gallery
3. Menus and Toolbars > CommandBar
4. Open the overflow menu through the ... button or Open/Close command bar buttons

Expected behavior
The height remains static.

Version Info
XAML Controls Gallery v.1.2.10.0

| Windows 10 version | Saw the problem? |
| :--------------------------------- | :-------------------- |
| Insider Build (xxxxx) | |
| May 2019 Update (18362) | Yes |
| October 2018 Update (17763) | |
| April 2018 Update (17134) | |
| Fall Creators Update (16299) | |
| Creators Update (15063) | |

| Device form factor | Saw the problem? |
| :-------------------- | :------------------- |
| Desktop | Yes |
| Mobile | |
| Xbox | |
| Surface Hub | |
| IoT | |

[jevansaks]

It could certainly be better, but the current behavior seems ok. I don't think it would be worth spending time fixing, especially given the recent troubles in fixing #275.

[kmgallahan]

It could certainly be better

It could certainly be not broken...

It goes from incorrect shortened height with cut off border to correct height with proper border at the click of a button, then goes back to the first state afterwards.

If it knows what height it should be while the menu is open then I'm not sure why it is sitting at the incorrect height the rest of the time.

It's also clearly an open bug with a stock control that hasn't had its style/theme overridden, unlike #275. Therefore I'm not sure why the issue should be closed...

With 225% scaling it just seems to be limited by the height of the "more" button until it is clicked:

[jevansaks]

Fair enough, we can keep it in the backlog.

[Felix-Dev]

The issue shouldn't be closed since this is incorrect behavior we notice here. While I understand the team having a large set of much bigger issues to tackle, keeping this issue open could be used by the community to take it on if the team has no resources available to address it in the forseeable future.

[kmgallahan]

A temporary fix for this could be to just set IsTextScaleFactorEnabled = false for the CommandBar. That doesn't follow guidance from the docs:

Use the platform controls

Did we say this already? It's worth repeating: When possible, always use the built-in controls provided with the various Windows app frameworks to get the most comprehensive user experience possible for the least amount of effort.

For example, all UWP text controls support the full text scaling experience without any customization or templating.

But the control would at least behave correctly.

In the future the relevant hard coded parameter(s) (just the *Height* ones?) mentioned here by @licanhua could be multiplied by the scale factor (1.25/1.5/1.75/2/2.25) via:

• Checking UISettings.TextScaleFactor on application startup
• Listening for the UISettings.TextScaleFactorChanged event

This could be a useful approach for other problematic controls as well. Example: scroll up to the screenshots that show the NavigationView's search box text getting cut off due to text scaling.

*Note: I'm not sure if direct multiplication of the height values by the scale multiple would provide the best numbers or not.