[Android] Fix for WebView Fails to Load URLs with Certain Encoded Characters

[praveenkumarkarunanithi]

Root Cause

The root cause of the issue is the use of Uri.IsWellFormedUriString for validating URLs in the WebView control. This method applies overly strict checks, including the IsWellFormedOriginalString test, which can incorrectly reject valid URLs, especially those containing encoded characters or international characters. This leads to improper handling of certain valid URLs, causing them to be treated as relative paths instead of absolute URLs.

Description of Change

In the WebView control, the URL validation logic in MauiWebView.LoadUrl has been updated to replace Uri.IsWellFormedUriString with Uri.TryCreate. This change ensures that a wider range of valid URLs, including those with encoded and international characters, are correctly handled as absolute URLs.

Issues Fixed

Fixes #26843
Fixes #23767
Fixes #23690
Closes #24002

Tested the behaviour in the following platforms

• Android
• Windows
• iOS
• Mac

Test case failing on windows. for more information: #27425

Screenshots

Before Issue Fix	After Issue Fix

[praveenkumarkarunanithi]

@dotnet-policy-service agree company="Syncfusion, Inc."

[jsuarezruiz]

/azp run

[jsuarezruiz]

/azp run

[jfversluis]

Build error

/Users/builder/azdo/_work/3/s/src/Core/src/Platform/WebViewHelper.cs(9,32): error CS1503: Argument 1: cannot convert from 'char' to 'string' [/Users/builder/azdo/_work/3/s/src/Core/src/Core.csproj::TargetFramework=netstandard2.0]

[MartyIX]

Build error

/Users/builder/azdo/_work/3/s/src/Core/src/Platform/WebViewHelper.cs(9,32): error CS1503: Argument 1: cannot convert from 'char' to 'string' [/Users/builder/azdo/_work/3/s/src/Core/src/Core.csproj::TargetFramework=netstandard2.0]

IMHO we hit #27003 (comment)

[MartyIX]

@praveenkumarkarunanithi IMHO it was OK as it was, the only thing that was necessary was to do:

internal static class WebViewHelper
{
    internal static bool IsRelativeUrl(string url)
    {
        // return !url.StartsWith('/') && !Uri.TryCreate(url, UriKind.Absolute, out _);
        return !url.StartsWith("/", StringComparison.Ordinal) && !Uri.TryCreate(url, UriKind.Absolute, out _);
    }
}

[praveenkumarkarunanithi]

@praveenkumarkarunanithi IMHO it was OK as it was, the only thing that was necessary was to do:

internal static class WebViewHelper
{
    internal static bool IsRelativeUrl(string url)
    {
        // return !url.StartsWith('/') && !Uri.TryCreate(url, UriKind.Absolute, out _);
        return !url.StartsWith("/", StringComparison.Ordinal) && !Uri.TryCreate(url, UriKind.Absolute, out _);
    }
}

@MartyIX, @jfversluis This fix is specific to the Android platform, creating a unit test would require significant changes to access the method within the unit test class for android. Instead, we added a UI test with assert validation to ensure the fix works across all platforms. This approach provides comprehensive coverage and validation without extensive refactoring. Let us know if you have further thoughts!

[jsuarezruiz]

/azp run

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[PureWeen]

WebViewShouldLoadEncodedUrl is failing

[jsuarezruiz]

WebViewShouldLoadEncodedUrl fails on Android.

Assert.Equal() Failure: Values differ\nExpected: Success\nActual: Failure

[jsuarezruiz]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[jsuarezruiz]

Ok, the tests are passing although I would review the use of VerifyInternetConnectivity.

Uri.IsWellFormedUriString in some scenarios, like including escaped characters, might cause to return false even for a valid URI. Uri.TryCreate is a safer and more robust choice because it both validates the URI and creates the object for further use if needed. In this case, we are creating the Uri object and not using it. Although it is not critical in performance and improves robustness.

[jsuarezruiz]

Is this necessary? Can't you use the VerifyInternetConnectivity(); existing method?

[praveenkumarkarunanithi]

@jsuarezruiz , The existing method (VerifyInternetConnectivity) is added in the UITest project, but since this is a different project (Device Test), I have added the method separately here.

[praveenkumarkarunanithi]

Ok, the tests are passing although I would review the use of VerifyInternetConnectivity.

Uri.IsWellFormedUriString in some scenarios, like including escaped characters, might cause to return false even for a valid URI. Uri.TryCreate is a safer and more robust choice because it both validates the URI and creates the object for further use if needed. In this case, we are creating the Uri object and not using it. Although it is not critical in performance and improves robustness.

@jsuarezruiz , Thanks for the feedback! You're correct—I'm currently discarding the created Uri object (out _). The main reason for using Uri.TryCreate here is its improved accuracy in validating URLs containing escaped characters, which Uri.IsWellFormedUriString incorrectly rejects.

[MarkusRodler]

@PureWeen How many months do we have to wait till this essential bugfix will be merged? This thing is basically done and works as expected (Thanks to @praveenkumarkarunanithi).