Fixed the crash on iOS when setting HeightRequest on WebView inside a ScrollView with IsVisible set to false

[Ahamed-Ali]

Root Cause of the issue

• When the WebView is placed inside a ScrollView, the height constraint can become infinite. The original code was using constraints directly, which could propagate infinite values. This caused layout issues and potential NaN exceptions.

Description of Change

• I have properly handled the infinite case for WebView in GetDesiredSize by using size.Width and size.Height instead of relying on potentially infinite constraints.

Regressed PR

• Change iOS SetNeedsLayout propagation mechanism #26629

Issues Fixed

Fixes #26795

Tested the behaviour in the following platforms

• Android
• Windows
• iOS
• Mac

Screenshot

Before Issue Fix	After Issue Fix
WebViewCrash.mov	WebViewFix.mov

[jsuarezruiz]

With this changes, the next conditions like:

if (size.Width == 0)

can use directly the width variable.

[Ahamed-Ali]

Thanks for the feedback, I have modified the changes @jsuarezruiz

[jsuarezruiz]

/azp run MAUI-UITests-public

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[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 -- 29022

Or

• Run remotely in PowerShell:

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

[Copilot]

Pull request overview

This PR addresses a crash on iOS when a WebView with HeightRequest is placed inside an invisible ScrollView. The fix modifies the GetDesiredSize method in WebViewHandler.iOS.cs to use the computed size dimensions instead of the constraint parameters directly, preventing infinite values from causing layout exceptions.

• Fixes iOS crash when WebView with HeightRequest is inside invisible ScrollView
• Updates GetDesiredSize to use size.Width/Height instead of widthConstraint/heightConstraint
• Adds UI test to prevent regression

Reviewed changes

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

File	Description
src/Core/src/Handlers/WebView/WebViewHandler.iOS.cs	Modified GetDesiredSize to use size dimensions instead of constraints to prevent infinite value propagation
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue26795.cs	Added NUnit UI test to verify WebView doesn't crash with HeightRequest in invisible ScrollView
src/Controls/tests/TestCases.HostApp/Issues/Issue26795.cs	Added test page reproducing the crash scenario with WebView inside invisible ScrollView

Comments suppressed due to low confidence (1)

src/Core/src/Handlers/WebView/WebViewHandler.iOS.cs:126

• The logic appears incomplete. When width or height is 0 and the constraint is valid and finite (not infinite, not <= 0), the code should fall back to using the constraint value.

Currently, if size.Width is 0 but widthConstraint is a valid finite value like 300, the code will leave width as 0 instead of using the constraint. This could cause incorrect layout calculations.

Consider adding an else clause to handle the case where constraints are valid:

if (width == 0)
{
    if (widthConstraint <= 0 || double.IsInfinity(widthConstraint))
    {
        width = MinimumSize;
        set = true;
    }
    else
    {
        width = widthConstraint;
        set = true;
    }
}

And similarly for height.

			if (width == 0)
			{
				if (widthConstraint <= 0 || double.IsInfinity(widthConstraint))
				{
					width = MinimumSize;
					set = true;
				}
			}

			if (height == 0)
			{
				if (heightConstraint <= 0 || double.IsInfinity(heightConstraint))
				{
					height = MinimumSize;
					set = true;
				}
			}

[Copilot]

The test only verifies that the app doesn't crash, but doesn't validate the actual layout behavior. Consider adding assertions to verify:

1. The WebView renders with the correct dimensions when made visible
2. The HeightRequest is respected
3. The layout works correctly when the ScrollView's IsVisible property is toggled

Example:

App.Tap("ToggleVisibilityButton");
App.WaitForElement("WebViewId");
var webViewRect = App.FindElement("WebViewId").GetRect();
Assert.That(webViewRect.Height, Is.GreaterThan(0));

This would provide more comprehensive coverage of the layout fix beyond just crash prevention.

[Copilot]

Consider adding an AutomationId to the WebView to enable more comprehensive UI testing of the layout behavior:

var webView = new WebView
{
    Source = "https://en.m.wikipedia.org/wiki",
    HeightRequest = 1000,
    AutomationId = "TestWebView"
};

This would allow the test to verify that the WebView is properly sized and positioned, not just that the app doesn't crash.

[Copilot]

Consider adding a button to toggle the ScrollView's visibility to enable more comprehensive testing:

var toggleButton = new Button
{
    Text = "Toggle Visibility",
    AutomationId = "ToggleVisibilityButton"
};
toggleButton.Clicked += (s, e) => scrollView.IsVisible = !scrollView.IsVisible;
layout.Children.Add(toggleButton);

This would allow the test to verify that the WebView layout works correctly both when initially invisible and when made visible.