[AI-Suggested] Content update request from Product Release signal: maui 10.0.110 #3560

Background

A recent product update has been released that may impact our documentation. This could include new features, changes to existing functionality, or other product enhancements.
Your Action Required: Please review the suggestions below and update the relevant documentation to ensure accuracy and completeness.

Signal Details:

• Title: maui 10.0.110
• Source URL: https://github.com/dotnet/maui/releases/tag/10.0.110
• Repository: https://github.com/dotnet/maui
• ReleaseWindowUtc: 2026-09-07 17:13:51Z - 2026-09-22 16:32:41Z
• TargetBranch: release/10.0.1xx-sr11
• currentTag: 10.0.110
• targetCommitish: release/10.0.1xx-sr11
• releaseUrl: https://github.com/dotnet/maui/releases/tag/10.0.110
• previousTag: 10.0.101

Source Signal Summary

Suggestions

Instructions for Copilot: Copilot should only fix suggestions with a checkmark and do not make any updates for unchecked suggestions.

• docs/user-interface/controls/entry.md:
  • [Improvements] Update the sections that define/describe when the Completed event fires (the introductory Completed event description and the Completed event section under “Create an Entry”) to clarify the Windows-specific behavior: Completed fires on an actual Enter key press sequence used to submit/finalize input, and does not fire when Enter is used only to confirm a Chinese/Japanese IME candidate on Windows. (PR #36577)
• docs/user-interface/controls/hybridwebview.md:
  • [Correction Required] Update the trimming/Native AOT guidance to remove/replace the claim that “In .NET 11 and later, HybridWebView can be used with full trimming and Native AOT when JavaScript-to-.NET invocation is registered with source-generated JSON metadata” and the associated instructions that rely on the JsonSerializerContext overload producing a trim-safe/AOT-safe dispatcher. The page must reflect the current behavior: JS↔.NET invocation is reflection/dynamic System.Text.Json-based (annotated with RequiresUnreferencedCode/RequiresDynamicCode) and the previous trimming-friendly overloads/interfaces described here were removed/replaced, so following the current instructions can lead to warnings and/or non-functional JS→.NET invocation in trimmed/AOT builds. (Impacts: the two “Important” callouts near the top, and the “Invoke C# from JavaScript” + “Pass complex types from JavaScript to C#” sections.) (PR #38126, PR #38155, PR #37393)
  • [Correction Required] Update the availability/registration behavior description to match the new runtime-feature gating: HybridWebViewHandler/IHybridWebViewTaskManager are registered only when RuntimeFeature.IsHybridWebViewSupported is enabled, and they are not registered under NativeAOT/TrimMode=Full. As written, the page implies that enabling trimming feature switches plus using the documented overload is sufficient; users can instead hit missing registration/feature-disabled behavior and be unable to complete the documented JS→.NET workflow. (Impacts: top-level “Important” about trimming/Native AOT availability and any section that implies JS→.NET invocation can be enabled for those configurations.) (PR #38126, PR #38155, PR #37393)
  • [Improvements] Add/adjust the JS→.NET invocation requirements to reflect the new message source/frame validation on Windows (WebView2) and iOS (WKWebView): messages from JavaScript are ignored (with debug logging) unless the sending message Source/frame URL is an absolute URI under the configured AppOriginUri. Without this, users who load content in subframes/iframes or navigate to content not under AppOriginUri will find that window.HybridWebView.SendRawMessage and window.HybridWebView.InvokeDotNet appear to stop working with no actionable explanation from the doc. (Impacts: introduction claims about “arbitrary HTML/JS/CSS” + “Invoke C# from JavaScript” section and JS library usage notes.) (PR #38126, PR #38155, PR #37393)
• docs/deployment/trimming.md:
  • [Improvements] Update the “Trimming incompatibilities” HybridWebView bullet and the “Trimming feature switches” entry for MauiHybridWebViewSupported (and its AppContext equivalent Microsoft.Maui.RuntimeFeature.IsHybridWebViewSupported) to explicitly state that HybridWebView is not supported/available under Native AOT and/or TrimMode=Full, because the required HybridWebView services/handler are not registered in those configurations; clarify that the feature switch does not make HybridWebView usable in those configurations. (PR #38126, PR #38155, PR #37393)
• docs/whats-new/dotnet-11.md:
  • [Correction Required] In the “Controls > HybridWebView JS-to-.NET invocation” section, remove or rewrite the claims that HybridWebView can use a source-generated JsonSerializerContext via SetInvokeJavaScriptTarget<T>(T target, JsonSerializerContext jsonSerializerContext) to avoid reflection and be compatible with NativeAOT/full trimming, and that “the legacy overload remains available”. Update this section to reflect that the JS↔.NET invocation contract is reflection-based and annotated as requiring unreferenced/dynamic code, and that the previously described trimming-friendly overloads/interfaces are no longer the supported contract. (PR #38126, PR #38155, PR #37393)
  • [Improvements] In the “Controls > HybridWebView JS-to-.NET invocation” section, add the new operational requirements that affect whether JS-to-.NET messages are processed: (1) messages are ignored unless the message Source/frame URL is an absolute URI under the configured AppOriginUri (Windows WebView2 + iOS WKWebView), which can otherwise break JS-to-.NET calls; and (2) the JS-to-.NET infrastructure (HybridWebViewHandler/IHybridWebViewTaskManager) is only registered when RuntimeFeature.IsHybridWebViewSupported is enabled, and is not registered under NativeAOT/TrimMode=Full, so users must not expect HybridWebView JS↔.NET invocation to work in those builds. (PR #38126, PR #38155, PR #37393)
• docs/whats-new/dotnet-11.md:
  • [Correction Required] Update the “Implicit XAML namespace declarations” section to remove/adjust the claim that implicit xmlns declarations are “enabled by default” and that root xmlns/xmlns:x can be omitted unconditionally. It must reflect that implicit XML namespace handling is gated by the [assembly: Microsoft.Maui.Controls.Xaml.Internals.AllowImplicitXmlnsDeclarationAttribute]; without it, XAML is treated as a full document and implicit default xmlns/prefix injection does not occur, so omitting the standard xmlns declarations can fail. (PR #38155)
  • [Correction Required] Update the “XAML Incremental Hot Reload” section to reflect that the XIHR flow described there has been removed/reverted. As written, users will expect XIHR to exist and may attempt to use the documented EnableMauiIncrementalHotReload opt-out property/workflow, which would no longer apply. The section must be revised so it no longer instructs users to rely on XIHR being enabled by default or controlled via that property under the current build targets/defaults. (PR #38155)
• docs/xaml/xamlc.md:
  • [Improvements] Update the article’s statements about defaults to reflect that new .NET MAUI templates set <MauiXamlInflator>SourceGen</MauiXamlInflator> by default, and clarify that the Debug=Runtime / non-Debug=XamlC defaults apply when MauiXamlInflator is not set (or when per-file MauiXaml Inflator is Default). This affects the introductory summary paragraph (“As of .NET 10, default inflation…”) and the “XAML Source Generation” section sentences implying SourceGen is not yet default (“will be enabled by default in the future”, “will become the future in new projects… soon”). (PR #38155)
• docs/xaml/fundamentals/get-started.md:
  • [Correction Required] Update the implicit namespace guidance to reflect that implicit default xmlns/prefix injection is NOT unconditional: revise the earlier note in “Anatomy of a XAML file” and the later “Implicit namespace declarations” section so they no longer claim the compiler injects the standard namespaces by default in .NET 11. Instead, document that implicit handling is gated by the assembly-level Microsoft.Maui.Controls.Xaml.Internals.AllowImplicitXmlnsDeclarationAttribute, and that without it users must keep explicit xmlns declarations or XAML parsing/build will fail when they omit them. (PR #38155)
  • [Correction Required] In the “Implicit namespace declarations” subsection, replace/adjust the current opt-in instructions that use DefineConstants (for MauiAllowImplicitXmlnsDeclaration) and EnablePreviewFeatures so the doc matches the new gating mechanism (assembly attribute). As written, the doc implies those project settings enable implicit namespaces; after the change, users could apply these settings, omit xmlns, and still encounter XAML parsing treated as a full document with no implicit injection. (PR #38155)
  • [Improvements] Revise the “XAML Source Generation” section to remove/adjust the statement that the feature is strictly opt-in and align the described defaults with the fact that templates now generate projects with <MauiXamlInflator>SourceGen</MauiXamlInflator> by default. Otherwise, users starting from current templates can be misled about what build behavior they are already using by default. (PR #38155)
• docs/xaml/namespaces/index.md:
  • [Correction Required] Update the "Implicit namespace declarations" section (including the .NET 11 default-on description and the .NET 10 preview opt-in instructions) to reflect that implicit injection of the standard xmlns and xmlns:x declarations is gated by the assembly-level Microsoft.Maui.Controls.Xaml.Internals.AllowImplicitXmlnsDeclarationAttribute, and that without it XAML is parsed as a full document and the implicit default xmlns/prefix injection will not occur. Ensure the doc no longer implies that omission will work unconditionally. (PR #38155)
• docs/xaml/hot-reload.md:
  • [Correction Required] Update the "Enable XAML Incremental Hot Reload" section to remove or replace the claims that XIHR exists/is enabled by default for Debug, that it enables XAML updates for dotnet watch, and that it can be opted out via the EnableMauiIncrementalHotReload MSBuild property; these statements must be aligned with the removal of the XIHR flow so users aren’t instructed to use a non-functional/non-existent mechanism. (PR #38155)
• docs/fundamentals/app-lifecycle.md:
  • [Improvements] In the “iOS and Mac Catalyst” section (the lifecycle delegates table entry for PerformActionForShortcutItem, and/or the surrounding guidance on registering handlers), add the requirement that every PerformActionForShortcutItem handler must call the provided completion callback exactly once, and that quick-action completion is aggregated across handlers (native completion is delayed until handlers return and completion callbacks are invoked; scene-delivered quick actions are handled through the same registrations). This prevents users from registering a handler that never completes and observing quick actions that appear to not work. (PR #38664)
• docs/fundamentals/accessibility.md:
  • [Correction Required] Update the "Semantic properties > Description" section warning bullet that says "Avoid setting the Description attached property on an Entry or Editor on Android. Doing so will stop Talkback actions functioning." to reflect the current Android behavior where SemanticProperties.Description is propagated to the native ContentDescription for Entry/Editor (and no longer implies TalkBack actions are broken by setting it). (PR #37276)
• docs/migration/native-essentials.md:
  • [Improvements] Update the Android guidance in Initialize the platform (including the code sample that currently derives MainActivity : Activity) to reflect that MediaPicker on Android requires the app’s current Activity to be an AndroidX.Activity.ComponentActivity (for example, an AppCompat-based Activity such as MauiAppCompatActivity) and that Platform.Init(this, savedInstanceState) must be called from OnCreate of that Activity; otherwise MediaPicker Pick*Async can throw InvalidOperationException even if the rest of Essentials initialization appears correct. (PR #38301, PR #38481)
• docs/platform-integration/communication/authentication.md:
  • [Correction Required] Update all Windows-related guidance to reflect that WebAuthenticator is unsupported on Windows (Windows implementation throws PlatformNotSupportedException), so Windows setup steps and behavior descriptions are not applicable. Affected areas include: "Get started" platform list, the Windows setup section (Package.appxmanifest protocol registration), and the "Platform differences" Windows subsection (including the statement about using WebAuthenticationBroker). Without this change, users will follow the documented Windows workflow and encounter unavoidable runtime failure. (PR #38664, PR #38155)
  • [Correction Required] Fix the Apple Sign In section statement that the non‑iOS web authentication flow "can also be used to enable Apple Sign In on your Android and Windows devices" to remove/adjust the Windows claim, because WebAuthenticator is unsupported on Windows and users would be misled into attempting a non-functional Windows sign-in flow. (PR #38664, PR #38155)
• docs/fundamentals/app-lifecycle.md:
  • [Correction Required] Update the Windows > Handle AppInstance activation section to remove or revise the claim that .NET MAUI uses AppInstance activation lifecycle to support WebAuthenticator callbacks on Windows, since WebAuthenticator is now unsupported on Windows (throws PlatformNotSupportedException). This section’s WebAuthenticator-specific guidance about redirecting protocol activations must be corrected to prevent users from attempting a non-working Windows WebAuthenticator workflow. (PR #38155)
• docs/user-interface/controls/map.md:
  • [Correction Required] Fix the Windows support guidance in the introductory "Important" callout(s) under the opening description (the section that currently says the Map control isn't supported on Windows and points to CommunityToolkit.Maui.Maps). Update/remove that statement so it no longer claims Windows is unsupported, and ensure it aligns with the later Windows guidance that the built-in Map uses WinUI 3 MapControl backed by Azure Maps and requires an Azure Maps subscription key. (PR #38155, PR #37154, PR #37265)
• docs/whats-new/dotnet-11.md:
  • [Correction Required] Update the "Platform features" section entries "MonochromeFile for Android adaptive icons" and "Themed splash screens" to remove or revise the claims/examples that MauiIcon supports MonochromeFile and MauiSplashScreen supports DarkFile/DarkColor/DarkTintColor, because these metadata-driven variants are not supported after the tooling change; otherwise users will configure these attributes and not get the documented results. (PR #33919, PR #37393, PR #38155)
• docs/whats-new/dotnet-10.md:
  • [Correction Required] Update the ".NET for Android" section "Recommended minimum supported Android API" to reflect the reverted template defaults (Android SupportedOSPlatformVersion now defaults back to 21 rather than 24). Without this change, users will form an incorrect understanding of the default minimum Android API used by generated .NET MAUI/.NET for Android projects. (PR #38155)
• docs/mac-catalyst/cli.md:
  • [Correction Required] In the main tutorial steps (the build/run section after creating the project), update the dotnet build -t:Run -f net8.0-maccatalyst command to use the .NET 10 Mac Catalyst TFM generated by current .NET MAUI templates (for example, net10.0-maccatalyst), so users can successfully build and run the newly created app. (PR #38155)

📚 To learn more about agentic content maintenance workflow, visit Agentic workflow for Learn content maintenance. Sign in using Learn Profile to access the content on this link.

💬 Share your feedback on the Learn Content Maintenance Agentic Workflow here.