[release/11.0.1xx-preview7] Reset WinUI Label line height to default

[kubaflo]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Description of Change

The ordered Label feature tests set LineHeight=3, then later option navigations replace the view model with the default LineHeight=-1. WinUI's UpdateLineHeight assigned a local TextBlock.LineHeight for positive values but ignored the default negative value, so the reused native TextBlock retained the old three-line-height setting. Recreating the page produced a fresh TextBlock with the correct default line height, causing 17 deterministic before/after screenshot mismatches.

This change:

• clears the WinUI TextBlock.LineHeightProperty when Label.LineHeight returns to its default negative value, restoring style/native-default precedence;
• adds a Windows device regression test covering the 3 to -1 transition;
• removes the disproven WinUI mapper-order experiment; and
• updates all 24 affected WinUI Label baselines from the correct default-line-height state. The final seven captures were byte-identical across all four retries in exact UI build 1538857.

Validation

• Exact build 1538707 disproved the mapper-order experiment: Android and iOS Label suites passed, while WinUI failed the same 17 post-LineHeight tests before and after retry.
• Exact head 5a702384e1 passed main build 1538856; Android, iOS, and MacCatalyst Label runs had no failed individual results in UI build 1538857; and Windows device run 42375462 passed LineHeight Resets To Default twice. The device pipeline was red only for two unrelated Android Entry tests already covered by [release/11.0.1xx-preview7] Preserve Android Entry text during handler reuse #37052.
• WinUI run 42376752 proved the original 17 failures fixed and left seven deterministic visual shifts. Every remaining actual capture was byte-identical across four retries, and each replacement now compares at zero RMS against that exact capture.
• Current head cd9f74f764 requires fresh exact-head /azp run proof for all WinUI Label tests and the Windows device regression test.

Issues Fixed

Contributes to stabilizing the .NET 11 Preview 7 UI-test branch.

[Copilot]

Copilot wasn't able to review any files in this pull request.

[kubaflo]

/azp run

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 37062

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 37062"

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[PureWeen]

I don’t think updating these shared baselines fixes the underlying failure. Each affected Label test compares the same baseline both before and after App.Tap(MainLabel). The target-branch evidence shows the pre-recreation screenshot passed while the post-recreation screenshot failed, so replacing the baseline with the post-recreation output is likely to move the failure to the first assertion rather than make both states match.

Suggested change: keep the existing baselines and preserve the page, navigation stack, toolbar, and surrounding layout. Put MainLabel in a stable host and recreate only that Label when tapped. Before removing the old Label, clear its binding context/detach its FormattedString; then insert a fresh Label with the same bindings, AutomationId, gesture handler, and name-scope behavior. This still exercises initial mapper application on a newly created handler without introducing page-level layout or toolbar changes.

This remains entirely test-host-only and preserves the intended invariant that rendering is identical before and after recreation.

[kubaflo]

Implemented the review feedback at abfbd0321b: all 17 baseline changes are reverted, the page/navigation/toolbar stay intact, and only MainLabel is recreated inside the existing stable host after detaching the old binding context and FormattedString. The replacement reuses the same style, bindings, automation ID, and gesture behavior.

[kubaflo]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[Copilot]

Pull request overview

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

Suppressed comments (3)

src/Controls/tests/TestCases.HostApp/FeatureMatrix/Label/LabelControlPage.xaml.cs:28

• _mainLabel = (Label)MainLabelHost.Children[0]; assumes the host has at least one child and that the first child is a Label. If the XAML changes (or is reordered), this will throw (IndexOutOfRange/InvalidCast) and fail the feature matrix page initialization. Consider validating count/type and producing a clearer failure.

		InitializeComponent();
		_mainLabel = (Label)MainLabelHost.Children[0];
		_viewModel = viewModel;

src/Controls/tests/TestCases.HostApp/FeatureMatrix/Label/LabelControlPage.xaml.cs:56

• CreateMainLabel sets BindingContext = _viewModel on the new Label. After the first tap, the Label has a local BindingContext, so later BindingContext = _viewModel = new LabelViewModel(); in NavigateToOptionsPage_Clicked will no longer propagate to the recreated label (it will keep the old VM). Rely on inherited BindingContext instead, or explicitly update _mainLabel.BindingContext when the page BindingContext changes.

		var label = new Label
		{
			Style = style,
			BindingContext = _viewModel,
		};

src/Controls/tests/TestCases.HostApp/FeatureMatrix/Label/LabelControlPage.xaml.cs:39

• PR title/description say this is a baseline-only update (“Update WinUI Label snapshots”), but this PR also changes the HostApp Label feature-matrix page behavior (recreating the main Label instance on tap and refactoring bindings into a Style). If the intent is baseline-only, these functional changes should be moved to a separate PR; otherwise, please update the description to mention the behavioral change so future archaeology doesn’t miss it.

	void MainLabel_Tapped(object sender, TappedEventArgs e)
	{
		var oldLabel = _mainLabel;
		var style = oldLabel.Style ?? throw new InvalidOperationException("MainLabel style is required.");

[kubaflo]

Follow-up d6faea8 removes the recreated Label local BindingContext, so it continues inheriting the page context when the Options flow replaces the view model. The HostApp builds successfully.

[kubaflo]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[kubaflo]

Head f86235a579 replaces the disproven handler-only workaround. Exact build 1538629 showed the workaround still left all 17 second screenshots mismatched and also correlated with broad Android/iOS/Mac Label failures after named elements were added to a page that re-runs InitializeComponent(). The new head restores the original test host, restores WinUI formatting-before-Text mapping, and installs the stable 24 px line-box captures. Merge proof requires all 94 WinUI Label tests—not only the 17 updated baselines—to pass both initial and post-recreation rendering.

[kubaflo]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[Copilot]

Pull request overview

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

Suppressed comments (1)

src/Core/src/Handlers/Label/LabelHandler.cs:22

• The comment says WinUI must apply “text formatting” before Text, but in this mapper TextColor and TextDecorations are intentionally applied after Text. That makes the comment misleading; suggest clarifying that only line-metric-affecting properties (font/alignment/character spacing/line height) must run before Text.

			// WinUI must apply text formatting before Text. Otherwise, a TextBlock
			// connected without text retains different line metrics when text is added later.

[kubaflo]

Head 5a702384e1 replaces the disproven mapper-order change with the root fix. Ordered test 10 leaves a local WinUI TextBlock.LineHeight from Label.LineHeight=3; later view models reset to -1, but the mapper previously ignored that value. The reused control therefore stayed at the old line height while the recreated control used the default. This head clears the dependency property on reset and adds a Windows device regression test. Merge proof still requires all 94 WinUI Label tests on this exact head.

[kubaflo]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[Copilot]

Pull request overview

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

[kubaflo]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[kubaflo]

Head cd9f74f764 adds the final seven WinUI Label baselines from exact UI build 1538857 / run 42376752. For every test, all four retry captures were byte-identical; the measured RMS differences exactly matched the reported 1.29%-6.57% failures, and each checked-in replacement now compares at zero. The prior 17 failures passed on the root-fix head. Fresh /azp run is queued to prove the complete exact head before merge.

[Copilot]

Pull request overview

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

[kubaflo]

@PureWeen current head cd9f74f764 is proven and ready to merge.

Exact-head evidence:

• All three builds use synthetic merge 4231dc4e9e, whose second parent is cd9f74f764.
• UI build 1539077: WinUI Label run 42382584 has 91 passed, 3 not executed, 0 failed; MacCatalyst Label run 42384542 has 84 passed, 5 not executed, 0 failed. The Android and iOS Label shards also completed successfully.
• Device build 1539078: both packaged and unpackaged LineHeight Resets To Default results passed in Windows run 42381766.

The remaining red legs are platform-isolated from this Windows-only diff: the two known Android long-Entry failures fixed by #37052, an iOS EntriesScrollingPageTest failure, and an iOS simulator boot timeout in integration tests.