[Windows] Fix for SemanticScreenReader.Default.Announce throws exception when called from MainPage constructor#30264
Conversation
|
Hey there @@HarishwaranVijayakumar! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed. |
jsuarezruiz
left a comment
There was a problem hiding this comment.
Could include a related test?
|
@jsuarezruiz, I attempted to write a test case for this scenario by invoking SemanticScreenReader.Announce() in the constructor. However, during test execution, the issue did not reproduce, and the test passed even without the fix. The exception was only observed in the HostApp when the page was instantiated directly using return mainPage ?? new Issue21121(). When the page was navigated to using CoreNavigationPage, the issue did not occur. |
| { | ||
| // If the window content is null, we can't announce anything yet. | ||
| // This can happen if the app is still starting up. | ||
| return; |
There was a problem hiding this comment.
This doesn’t exactly fix the issue in question, right?
We’re just avoiding the crash when window.Content is null. But this ends up silently skipping the announcement if the visual tree isn’t ready. Now the user gets no feedback, the announcement just doesn’t happen. No crash, no warning, just silence.
From what I understand, on Windows, we need to locate a control with an automation peer to perform the announce operation. If that’s the expected behavior, maybe we shouldn’t silently skip here.
Instead, could we consider throwing a meaningful exception with a helpful message, so users know they’re calling Announce() too early and can fix it by moving the call to a better place?
There was a problem hiding this comment.
@bhavanesh2001 Throwing an exception in an accessibility scenario is not an appropriate approach. Accessibility features are intended to enhance the user experience, not disrupt it. If a screen reader announcement fails, the application should continue functioning normally.
A better approach would be to return silently along with logging the issue using diagnostic tools such as Debug.WriteLine. This ensures that the failure is recorded for developers without affecting the user experience. In the Essentials project, diagnostic logging is commonly used to capture such errors without interrupting the app’s flow.
https://github.com/dotnet/maui/blob/main/src/Essentials/src/Permissions/Permissions.ios.cs#L38
@PureWeen, your thoughts?
There was a problem hiding this comment.
@sheiksyedm Just to clarify ,I wasn’t suggesting we should throw on end users’ devices. My point was to help devs catch the issue early, rather than silently skipping the announcement without any signal.
By users, I meant devs using the API, not app users.
There was a problem hiding this comment.
Pull request overview
This PR fixes a Windows-specific crash where SemanticScreenReader.Default.Announce() throws a NullReferenceException when called during early application initialization (e.g., from MainPage constructor). The fix adds a null check for window.Content before attempting to find the automation peer.
Key changes:
- Adds null check in Windows SemanticScreenReader implementation to prevent crashes during early initialization
- Updates maui-mobile template with visual refinements (Border background handling, Visual State Management improvements)
- Adds UI test infrastructure improvements (Done button accessibility, test coverage for various issues)
- Platform-specific fixes for iOS (WebView navigation, SwipeView, Slider tap-to-move, TabBar iOS 18/26 handling)
- Android fixes (activity result registration, SwipeView touch propagation)
- Windows fixes (ContentView background, transformation NaN handling)
Reviewed changes
Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/Essentials/src/SemanticScreenReader/SemanticScreenReader.windows.cs | Core fix: Adds null check for window.Content to prevent NullReferenceException during early initialization |
| src/Templates/src/templates/maui-mobile/* | Template refinements: Border background moved from global style to specific usage, improved Visual State setters consistency |
| src/TestUtils/src/Microsoft.Maui.IntegrationTests/WindowsTemplateTest.cs | Adds test for Microsoft.Identity.Client package compatibility with Windows template |
| src/Essentials/src/Platform/ActivityForResultRequest.android.cs | Prevents activity launcher re-registration from temporary activities |
| src/Core/src/Handlers/ContentView/ContentViewHandler.Windows.cs | Adds IsHitTestVisible and background handling for ContentView on Windows |
| src/Core/src/Handlers/Slider/SliderHandler.iOS.cs | Implements tap-to-move functionality for iOS Slider |
| src/Core/src/Platform/iOS/MauiDoneAccessoryView.cs | Adds accessibility identifier to Done button for UI testing |
| src/Core/src/Platform/iOS/TabbedViewExtensions.cs | Adds iOS 26+ check to disable iOS 18 toolbar tab workaround |
| src/Core/src/Platform/iOS/MauiWebViewNavigationDelegate.cs | Fixes target="_blank" link handling in WebView |
| src/Core/src/Platform/iOS/MauiSwipeView.cs | Fixes SwipeView threshold calculation for Left/Up directions |
| src/Core/src/Platform/Android/MauiSwipeView.cs | Prevents parent touch propagation during swipe gestures |
| src/Core/src/Platform/Windows/TransformationExtensions.cs | Adds NaN validation for rotation values |
| src/Core/tests/DeviceTests/Services/ImageSource/StreamImageSourceServiceTests.Android.cs | Re-enables Android test with improved color assertion |
| src/Controls/tests/Xaml.UnitTests/Issues/Maui28711.xaml* | Adds test for x:Name on SolidColorBrush in Resources |
| src/Controls/tests/Xaml.UnitTests/Issues/Maui27202.xaml* | Adds test for Visual State Manager inheritance in derived styles |
| src/Controls/tests/UITests/Tests/Issues/Issue15810.cs | Adds UI test for TapGestureRecognizer on Windows |
| src/Controls/tests/TestCases/Issues/Issue15810.cs | Adds test case for TapGestureRecognizer issue |
| src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/MauiDoneAccessoryButton.cs | Adds UI test for Done button accessibility |
| src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/* | Screenshot snapshots for iOS UI tests |
| src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/* | Screenshot snapshots for Windows UI tests |
…ion when called from MainPage constructor (#30264) * Added fix * Modified fix * Space added * Updated the fix
…ion when called from MainPage constructor (#30264) * Added fix * Modified fix * Space added * Updated the fix
…ion when called from MainPage constructor (#30264) * Added fix * Modified fix * Space added * Updated the fix
…ion when called from MainPage constructor (#30264) * Added fix * Modified fix * Space added * Updated the fix
…ion when called from MainPage constructor (#30264) * Added fix * Modified fix * Space added * Updated the fix
…ion when called from MainPage constructor (#30264) * Added fix * Modified fix * Space added * Updated the fix
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!
Issue Details
Root Cause of the issue
Description of Change
Issues Fixed
Fixes #21121
Tested the behaviour in the follwing platforms
Output