Improve Net11 TextBox text layout by reducing excess vertical whitespace

[SimonZhao888]

Root Cause

Under the Net11 modern style, inconsistencies have arisen in the calculations regarding the "external height contract" and the "internal available client area" for TextBox, ComboBox, and UpDown controls. On one hand, they retain the height semantics of classic single-line edit controls (Everett); on the other, they introduce a more aggressive modern "chrome/padding carve." This combination leads to two types of issues in scenarios involving small heights, AutoSize settings, or DPI/text scaling:

1. The client height is excessively compressed (risking text visibility);
2. Alternatively, visual whitespace is increased to avoid compression (inconsistent with height expectations for classic controls).

Proposed changes

• TextBoxBase: Reverted PreferredHeightCore to the classic formula (maintaining compatibility with existing contracts); added a minimum single-line client height safeguard for the modern padding "carve" within WM_NCCALCSIZE, and implemented tiered compression of the top/bottom carve based on border visibility to prevent the text area from being crushed.
• ComboBox (Modern): Aligned the preferred height in modern mode with the classic height; adjusted the modern chrome inset to "preserve horizontal spacing while minimizing vertical spacing," thereby reducing excess vertical whitespace while maintaining text readability.
• UpDownBase: Introduced a constant for modern button width (14 logical units) and applied it to the button group width; added adaptive vertical carve compression to the modern layout (while preserving a minimum visible border strip); implemented extended top/bottom border rendering to improve the continuity of rounded borders.
• ModernControlVisualStyles: Standardized and reduced the relevant corner radii (for Field and UpDown controls) to align with the new geometric and border visual style.
• Tests: Performed a batch update and added new tests covering classic height contracts, AutoSize/layout stability, minimum text measurement safeguards in DPI scenarios, and padding boundaries versus border visibility.

Customer Impact

• Single-line input controls using the modern style are more stable across different DPI and text scaling settings: they are less prone to text clipping or unexpected increases in height and whitespace.
• Layouts that rely on preferred height—such as TableLayoutPanel—behave more predictably, with fewer visual jumps.
• Compatibility with legacy WinForms height behavior is maintained, reducing the risk of regressions when upgrading existing applications to the new style.

Screenshots

Before

After

Scale 350%

Scale 300%

Scale 225%

Scale 150%

Scale 100%

Test methodology

• Manually
• Automated test cases

Test environment(s)

• 11.0.0-preview.7.26381.103

Microsoft Reviewers: Open in CodeFlow

[SimonZhao888]

Issue 1

When the screen scale is set to 225% or higher, text within TextBox and NumericUpDown controls under .NET 11 is not fully displayed; parts of the text are obscured by the bottom border.

[Copilot]

Pull request overview

This PR refines single-line TextBox layout under VisualStylesMode.Net11 by reducing excess vertical whitespace and stabilizing the text-to-border geometry while keeping classic compatibility expectations.

Changes:

• Align modern PreferredHeight behavior with the classic (Everett) preferred-height formula.
• Add single-line client-area carve adjustments during WM_NCCALCSIZE to prevent overly large vertical padding from shrinking the usable text area.
• Update/add unit tests to assert the new preferred-height and non-client/client-area behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/System.Windows.Forms/System/Windows/Forms/Controls/TextBox/TextBoxBase.cs	Changes modern preferred-height selection and adjusts single-line padding carve logic in WM_NCCALCSIZE.
src/test/unit/System.Windows.Forms/TextBoxBaseTests.cs	Updates existing tests and adds regression tests for preferred height, padding, and border/non-client behavior in Net11 mode.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/test/unit/System.Windows.Forms/TextBoxBaseTests.cs:226

• The minimum client-height assertion uses a hard-coded "+ 3" pixels, which can be incorrect when the test is executed under non-96 DPI. The production code scales this margin with DPI (LogicalToDeviceUnits/ScaleToDpi), so the test should scale the 3px term as well to avoid DPI-dependent failures.

        Assert.True(control.ClientSize.Height >= control.Font.Height + 3);

src/test/unit/System.Windows.Forms/TextBoxBaseTests.cs:246

• This pixel-based border assertion may be flaky because the control BackColor is set to White, which can match the rendered border color in some themes/high-contrast configurations. Using an uncommon BackColor reduces the chance of accidental equality while still validating that the top/bottom border pixels are not client-filled.

            BackColor = Color.White,
            ForeColor = Color.Black,
            Size = new Size(120, s_preferredHeight)
        };

[KlausLoeffelmann]

There is the issue, which I think also Copilot pointed out in the reviews (at least it is slightly related), that the system-reservation of the Padding will probably be scaleing-up badly.

And, I think that is already the case, because if you watch closely, you see that the TextBox' inner native rectangle is reaching just slightly in our rounded border.

Let's make the rounded rectangle more edgy - and see how that looks. If you reduce the radius, the edges become steeper, and it might also mitigate the bad anti-alias of the rounded rectangle better. And I think we can reduce the radius here considerably.

[SimonZhao888]

And, I think that is already the case, because if you watch closely, you see that the TextBox' inner native rectangle is reaching just slightly in our rounded border.

Done.