Improve Net11 TextBox text layout by reducing excess vertical whitespace

[SimonZhao888]

Root Cause

Under VisualStylesMode.Net11, the TextBox employs a new rendering model featuring rounded corners and a modern border style; however, the usable text area of ​​single-line text boxes remains subject to the combined influence of legacy height-compatibility formulas and modern padding "carve" logic. The superposition of these two measurement models results in uneven padding distribution—particularly in the vertical dimension:

1. The spacing between the text area and the border is excessive, creating too much visual whitespace;
2. Under specific scaling or height constraints, the positioning of the text relative to the border becomes unstable (e.g., characters with descenders are more prone to touching the edge or being compressed);
3. This behavior deviates from the expected WinUI style (which features a double-line focus indicator and a more compact text area).
   Consequently, the primary objective of this modification is to standardize the geometric relationship between the text area and the border in Net11 mode, reduce unnecessary whitespace, and ensure more consistent behavior for single-line TextBox controls across various border styles and scaling levels.

Proposed changes

• Adjusted Net11 TextBox single-line client-area carving to reduce excess vertical whitespace and improve text-to-border balance.
• Tuned modern padding behavior so single-line rendering aligns with current Net11 layout expectations across border styles.
• Updated TextBoxBase unit tests to match intended modern layout behavior (padding expectations and preferred-height assertions).
• Added/updated regression coverage around non-client band/padding behavior to prevent future spacing regressions.

Customer Impact

• Text in Net11 TextBox appears visually better centered with less unnecessary blank space.
• Improves readability and consistency for common single-line input scenarios.
• Reduces UI polish issues where text felt too far from the bottom border.
• No API surface change; impact is visual/layout refinement with compatibility-focused behavior preserved.

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.