BlazorWebView: ignore query‑string dots in IsBaseOfPage

[tw4]

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

BlazorWebView’s force reload logic misidentified query‑string dots (?weight=62.5, etc.) as file‑extension dots, so the page was treated as a file and an empty “There is no content at url” screen appeared.
UriExtensions.IsBaseOfPage now calls Path.HasExtension(uri.AbsolutePath), evaluating only the path (AbsolutePath) segment, so dots in the query or fragment no longer trigger the false file‑extension check.

Fixes #25689

[Copilot]

Pull Request Overview

This PR fixes an issue in BlazorWebView where query‑string dots were incorrectly interpreted as file‑extension dots, leading to a faulty file-loading behavior. The changes update the UriExtensions.IsBaseOfPage method to evaluate the AbsolutePath of the URI instead of the entire URI string.

• Update null/whitespace check and URI parsing.
• Change file extension check from the entire URI to its AbsolutePath segment.

[dotnet-policy-service]

Hey there @@tw4! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[tw4]

@dotnet-policy-service agree

[Copilot]

Pull Request Overview

This PR fixes an issue in BlazorWebView where query‑string dots were mistakenly interpreted as file‑extension dots, preventing proper page loading.

• Updated IsBaseOfPage in UriExtensions to use the AbsolutePath for extension check.
• Added guard clauses for null/whitespace and validated the URI scheme before checking for file extensions.

Comments suppressed due to low confidence (1)

src/BlazorWebView/src/Maui/Extensions/UriExtensions.cs:19

• Ensure that test cases in TestCases.HostApp and TestCases.Shared.Tests cover scenarios with query-string dots so that the updated logic in IsBaseOfPage behaves as expected.

if (Path.HasExtension(uri.AbsolutePath))

[mattleibow]

Thanks for the PR, but please add some unit tests of common URLs that this will fix and add the corner cases that this may trip up on.

[tw4]

Thank you for your feedback.

I tried to create the unit tests directly within the Maui project, but I ran into a few issues. Because the class is internal and due to some SDK-related errors, I wasn’t able to write the tests inside the project itself. Instead, I created a separate project to write the unit tests and verify the fix, although I realize this isn’t the ideal approach.

If you prefer, you can close this PR. I haven’t been able to set up proper unit testing within the Maui project yet. Still, I wanted to share my progress and make sure that the main bug is covered by tests—even though the tests are currently in an external project.

Thank you for your understanding.

repo:https://github.com/tw4/MauiUnitTest

Screen.Recording.2025-05-15.at.21.52.05.mov

[mattleibow]

I see, maybe add an the internals visible attribute in here for the device tests: https://github.com/dotnet/maui/blob/342b2730b05bbf3559ee6a167efa4ea135dff375/src/BlazorWebView/src/Maui/Properties/AssemblyInfo.cs

[assembly: InternalsVisibleTo("Microsoft.Maui.MauiBlazorWebView.DeviceTests")]

It would have been ideal to have a unit tests project that runs faster to test things that don't need to be on device, but we don't have that yet so a device test is fine.