[Testing] Fixed test failure in PR 34885 - [04/14/2026] Candidate - 2#35056
Closed
TamilarasanSF4853 wants to merge 103 commits intodotnet:inflight/candidatefrom
Closed
[Testing] Fixed test failure in PR 34885 - [04/14/2026] Candidate - 2#35056TamilarasanSF4853 wants to merge 103 commits intodotnet:inflight/candidatefrom
TamilarasanSF4853 wants to merge 103 commits intodotnet:inflight/candidatefrom
Conversation
…net#34527) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Issue Details: Horizontalspacing / Verticalspacing is not not applied to the first column in GridItemLayout using CollectionView on Android platform. ### Root Cause: The grid spacing was not being distributed symmetrically across the active layout implementations, so edge items did not fully participate when spacing changed at runtime. ### Description of Change: - On Android, the fix in MauiRecyclerView.cs changes how RecyclerView padding is handled for GridItemsLayout. Android was already using SpacingItemDecoration, which applies half-spacing on all four sides of each item. Previously, negative RecyclerView padding canceled that spacing at the control edges. The branch keeps that negative-padding behavior for non-grid layouts, but disables it for GridItemsLayout, allowing the grid’s half-spacing to remain visible at the outer perimeter. This makes the first row and first column visually respond when spacing changes, but it also changes the grid behavior from spacing only between items to spacing around the outside edges as well. **Tested the behavior in the following platforms:** - [x] Android - [x] Windows - [ ] iOS - [ ] Mac ### Reference: N/A ### Issues Fixed: Fixes dotnet#34257 ### Screenshots | Before | After | |---------|--------| | <Video src="https://github.com/user-attachments/assets/578dda69-1d60-474c-a6d8-23b3f9d29a50" Width="300" Height="600"> | <Video src="https://github.com/user-attachments/assets/7f3826e6-5922-4b6f-a6b9-de581b7db6c3" Width="300" Height="600"> |
### Description of Change Compare collection items with value equality ### Issues Fixed Fixes: dotnet#33487 <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. -->
…crollView (dotnet#34352) > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! This PR enhances the event handling support for multiple MAUI controls by adding comprehensive implementation and validation for control-specific events, along with corresponding test coverage. The update includes the addition of events for Slider and ScrollView controls, ensuring proper event triggering and argument handling across different platforms.
) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Issues Fixed Fixes dotnet#23854 |Before|After| |--|--| |<img src="https://github.com/user-attachments/assets/104904bd-180d-44a0-ad91-51c83611af60" width="300px"/>|<img src="https://github.com/user-attachments/assets/b838132f-a3cf-4bf8-8e2b-641a9c1b55d4" width="300px"/>|
…items source (dotnet#24610) ### Description of Change Any control derived from `ItemsView` (`CarouselView`, `CollectionView`) never disconnected from the `ItemsSource.CollectionChanged` callback when `DisconnectHandler()` is called. If the lifetime of the item source outlives the controls it can result in the `CollectionChanged` callback keeping part of the UI tree alive in a half-zombie state. Any change then calls the callback and it may cause crashes with `NullReferenceException` as seen in dotnet#24304. ### Issues Fixed Fixes dotnet#24304
…sed by missing ClipData (dotnet#34417) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Details - `Share.RequestAsync` logs `SecurityException` on Android 10+ ### Root Cause of the issue - Missing `ClipData` on the file share intent — Android 10+ uses `ClipData` (not `EXTRA_STREAM`) to propagate URI permission grants through the chooser - `chooserIntent.SetFlags(ClearTop | NewTask)` was missing `GrantReadUriPermission`, so the chooser process (share sheet UI, uid=1000) couldn't read the FileProvider URI to show preview thumbnails ### Description of Change <!-- Enter description of the fix in this section --> Enhancements to Android file sharing: * Ensured that `ClipData` is set on share intents for both single and multiple files, granting URI read permissions to receiving apps and preventing `SecurityException` on Android 10+ when accessing shared files. * Extracted the intent creation logic into a new `CreateShareFileIntent` method, making it easier to test without launching an activity. Test improvements: * Added unit tests for Android to verify that `ClipData` is correctly set for both single and multiple file share intents, ensuring shared URIs are accessible. Codebase maintenance: * Added missing `using System;` directive and aliased `AndroidUri` for clarity in `Share.android.cs`. * Updated test file imports to include necessary namespaces for file operations and storage. ### Issues Fixed <!-- Please make sure that there is a bug logged for the issue being fixed. The bug should describe the problem and how to reproduce it. --> Fixes dotnet#34370 ### Tested the behaviour in the following platforms - [ ] - Windows - [x] - Android - [ ] - iOS - [ ] - Mac | Before | After | |----------|----------| | <video src="https://github.com/user-attachments/assets/dc1583d6-ba7a-4089-a289-acfb44828934"> | <video src="https://github.com/user-attachments/assets/bd678a0b-d62e-4253-9b46-03f7a6751e65"> | <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. -->
…onView (dotnet#27230) ### Issue Details When VisualState setters are defined, then firstly the elements are not displayed correctly on initial render and then the visual state isn't changed when an item is selected. ### Root Cause In the Realize() method within ItemContentControl.cs, the Content is assigned first. As a result, the visual representation is initialized before the element is added to the logical tree. This sequence may cause styles and Visual State Manager (VSM) states to not apply immediately, as styles are typically applied after an element becomes part of the logical tree. ### Description of Change Windows: Assigning the Content after adding the element to the ItemsView logical tree, ensuring immediate application of styles and VSM states. ### Validated the behaviour in the following platforms - [ ] Android - [x] Windows - [ ] iOS - [ ] Mac ### Issues Fixed Fixes dotnet#27086 Fixes dotnet#19209 Fixes dotnet#18701 ### Screenshots | Before | After | |---------|--------| | <video src="https://github.com/user-attachments/assets/6cb4c24c-d091-41f7-96a7-cb5ef96aaed3"> | <video src="https://github.com/user-attachments/assets/c9ee9849-e927-4f9f-bbd7-66d1e6bc869b" > |
… its child content. (dotnet#30080) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Details: BindingContext of the Window TitleBar is not being passed on to its child content (Content, LeadingContent, TrailingContent). ### Description of Change <!-- Enter description of the fix in this section --> * Added an override for the `OnBindingContextChanged` method in the `TitleBar` class to propagate the `BindingContext` to its child elements (`Content`, `LeadingContent`, and `TrailingContent`). * Updated the `OnLeadingChanged`, `OnContentChanged`, and `OnTrailingContentChanged` methods to clear and reapply the inherited `BindingContext` when the respective properties change. Validated the behaviour in the following platforms - [ ] Android - [x] Windows - [ ] iOS - [x] Mac ### Issues Fixed <!-- Please make sure that there is a bug logged for the issue being fixed. The bug should describe the problem and how to reproduce it. --> Fixes dotnet#24831 <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. --> ### Output | Before | After | | ------ | ----- | | <img width="793" alt="Before" src="https://github.com/user-attachments/assets/4fc607b1-8e46-42ae-8eda-71720753abad" /> | <img width="793" alt="After" src="https://github.com/user-attachments/assets/594a970d-70af-4cc4-b496-cb3fcee73b1f" /> | --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Jakub Florkowski <kubaflo123@gmail.com>
…otnet#29897) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Detail The Margin property is not applied as expected when used within the EmptyView of a CollectionView. Note: Issue not replicated in Android, iOS and Mac platforms in latest. ### Root Cause The Margin set on the EmptyView is not automatically applied to the native container (ContentControl) on the Windows platform, resulting in incorrect layout spacing. ### Description of Change Applied the EmptyView’s Margin explicitly to the _emptyView.Marging to ensure consistent layout rendering on Windows. ### Validated the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Issues Fixed: Fixes dotnet#8494 ### Screenshots | Before | After | |---------|--------| | <img src="https://github.com/user-attachments/assets/23f75266-60ec-4888-a177-bc484178c000"> | <img src="https://github.com/user-attachments/assets/6e9593df-f7fb-433c-994d-8462d6c528ac"> |
<!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Root Cause of the issue - The SearchHandler property values such as TextColor, CancelButtonColor, BackgroundColor, CharacterSpacing, HorizontalTextAlignment, and TextTransform, are not being set to the native control. ### Description of Change - The missing SearchHandler property values are now correctly applied to the native control, and it is functioning as expected. ### Issues Fixed Fixes dotnet#29493 ### Tested the behaviour in the following platforms - [x] Windows - [x] iOS - [x] Android - [x] Mac ### Screenshot | Before Fix | After Fix | |----------|----------| | <video src="https://github.com/user-attachments/assets/5dff4655-f661-4521-9a86-4101fd54cd74"> | <video src="https://github.com/user-attachments/assets/666c10d8-791e-4083-9d1c-e5feb757103b"> | --------- Co-authored-by: Subhiksha Chandrasekaran <subhiksha.c@syncfusion.com>
…fied on the label inside a VerticalStackLayout with specified width request (dotnet#29166) - Label text gets cropped when a width request is specified on the label inside a VerticalStackLayout with specified with request on iOS and macOS platform. - The label height is not calculated correctly because the label size is obtained from SizeThatFits by passing the layout's height and width instead of the label's own dimensions. As a result, the label gets cropped. - With Background, the label height is not calculated correctly because the label size is obtained from SizeThatFits by passing the layout's height and width instead of the label's own dimensions. As a result, the label gets cropped. - When setting a width request on the Label control without background, it should check IsExplicitSet for both width and height requests and obtain the size using SizeThatFits by passing the explicit width and height requests in the ViewHandlerExtension.iOS class. - When setting a width request on the Label control with background, label platform view of wrapper view calculated the size using layout instead of label. Validated the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac Fixes dotnet#28660 Fixes dotnet#26644 iOS | Before | After | |---------|--------| |<img src="https://github.com/user-attachments/assets/36443d60-2f30-4eb9-a042-4aa3d9dbfa80" width="300" height="600"> | <img src="https://github.com/user-attachments/assets/1175b6fc-7a16-49c6-b680-24bfc47a7574" width="300" height="600"> | macOS | Before | After | |---------|--------| |<img src="https://github.com/user-attachments/assets/c440c95c-ec06-4276-998d-5d0e9ddd54cf" />| <img src="https://github.com/user-attachments/assets/edea5803-9248-4571-a96b-0fdeedc3bb59" > | ---------
…vigation is in progress - fix (dotnet#31016) ### Description of Change By skipping view controllers that are being dismissed (animation is happening, for example ), we ensure DisplayAlert() and other popups are shown only on valid, active UI stacks, preventing the deadlock and improving reliability on iOS/macOS. ### Issues Fixed Fixes dotnet#30970
…net#25129) ### Root Cause **Android** The text alignment property of the Android EditText does not update at runtime, causing the text alignment to remain unchanged. **iOS and MAC** Runtime changes to vertical text alignment are not handled for placeholders on both iOS and macOS platforms. As a result, the placeholder text remains at the start position. Additionally, horizontal text alignment is not supported for placeholder label. ### Description of Change **Android** We can resolve this issue by using gravity along with the text alignment logic. **iOS and MAC** For vertical text alignment, we can relayout the placeholder label whenever the value changes. Since MauiTextView is derived from UITextView, we can override the TextAlignmentProperty and set its value directly to UITextView. At the same time, we can apply the same value to the placeholder label. This ensures that both the text view and the placeholder label are perfectly aligned. Validated the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Issues Fixed Fixes dotnet#10987 Fixes dotnet#30052 ### Output | Before | After | |---------|--------| | <video src="https://github.com/user-attachments/assets/3fee7ec0-524e-480a-a647-b20048962afb" width="320" height="240" controls></video> | <video src="https://github.com/user-attachments/assets/1d384972-2089-4ff0-9be9-f243d013eac5" width="320" height="240" controls></video> | | <video src="https://github.com/user-attachments/assets/7a497a50-7429-4569-8ba1-3f1dab4e6c66" width="320" height="240" controls></video> | <video src="https://github.com/user-attachments/assets/1b676c4d-7c2d-40e7-abd6-6019c14ab6d8" width="320" height="240" controls></video> | | <video src="https://github.com/user-attachments/assets/43484d4c-26ef-4165-b27e-a2263e64a180" width="320" height="240" controls></video> | <video src="https://github.com/user-attachments/assets/4938a5f1-cc2f-4a51-9619-6a80969a2def" width="320" height="240" controls></video> | #### Windows working fine in windows platform. https://github.com/user-attachments/assets/80c0f376-782b-4275-b4f1-f25fe9ec0326
…otnet#34565) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Issue Details - On Android, abnormal behavior occurs when an AbsoluteLayout with small dimensions is used as a parent, contains child views, and has its opacity set to a value less than 1. In this scenario, the rendering of the child views becomes incorrect. ### Root Cause - On Android, when a ViewGroup has Alpha < 1 and HasOverlappingRendering returns true (default behavior), the system renders its children into an offscreen buffer constrained to the view’s bounds before applying the alpha. While this avoids double blending, it also causes any child content that overflows the parent’s bounds to be clipped, regardless of layout configuration. ### Description of Change - Overrode the HasOverlappingRendering property in ContentViewGroup, LayoutViewGroup, and WrapperView to return false when Alpha < 1.0f, ensuring that Android does not use an offscreen buffer that clips overflowing children for semi-transparent layouts. - Updated the public API to include the new overrides for HasOverlappingRendering in the relevant classes ### Issues Fixed Fixes dotnet#22038 ### Validated the behaviour in the following platforms - [ ] Windows - [x] Android - [ ] iOS - [ ] Mac ### Output | Before | After | |----------|----------| | <img src="https://github.com/user-attachments/assets/1f8f7513-f6ae-42db-a1a2-4b7d0b0d30b5"> | <img src="https://github.com/user-attachments/assets/e94121fd-9c52-48ae-b033-2475192576cf"> |
…correct during animated ScrollTo() (dotnet#34570) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Root Cause **Android**: `CarouselView` is backed by `RecyclerView`, which emits intermediate position callbacks during animated programmatic navigation `(e.g., 0 → 1 → 2 → 3)`. These intermediate callbacks were incorrectly updating `PreviousPosition` and `PreviousItem`, causing the final values to reflect the last intermediate step instead of the true starting position. **Windows**: `CarouselView.ScrollTo()` triggers an animated scroll via WinUI `ScrollViewer`, which raises `ViewChanged` events for each animation frame `(e.g., 1 → 2 → 3)`. These intermediate events committed transient `positions` as the current Position, resulting in incorrect `PreviousPosition` and `PreviousItem` values being captured. ### Description of Change **Android**: Properly reused the existing `_gotoPosition` guard for animated programmatic navigation. The logical target index (`args.Index`) is now stored before animated `ScrollTo()` begins. Using the logical index instead of the looped adapter position ensures the guard works correctly in both Loop and non-Loop modes. The premature clearing of `_gotoPosition` in the position update path was also removed. This ensures intermediate callbacks are ignored and `PreviousPosition/PreviousItem` update only when the intended target is reached. **Windows**: Implemented an early-commit approach aligned with the Android fix and adapted to WinUI’s async animation model. The target position is committed before the animation starts, ensuring `PositionChanged` fires with correct previous values while the visual animation proceeds. A guard flag suppresses intermediate `ViewChanged` updates and re-entrant scroll calls during animation and is cleared safely after completion, including error scenarios. An additional safeguard prevents initial layout events from overriding the configured starting position. ### Issues Fixed Fixes dotnet#29544 Tested the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Screenshots **Android:** | Before Issue Fix | After Issue Fix | |------------------|-----------------| | <video width="350" alt="withoutfix" src="https://github.com/user-attachments/assets/38ae2b0f-4c8f-4452-a72f-73c849c061a6" /> | <video width="350" alt="withfix" src="https://github.com/user-attachments/assets/fd31e15f-512b-40e9-8625-d6411d7e4967" /> | **Windows:** | Before Issue Fix | After Issue Fix | |------------------|-----------------| | <img width="350" alt="withoutfix" src="https://github.com/user-attachments/assets/f287aae9-510a-4b1d-8e53-08cb1a52fb06" /> | <img width="350" alt="withfix" src="https://github.com/user-attachments/assets/aab19d5b-c807-4536-a093-9a31a28a02a0" /> |
…nd layout options (dotnet#34533) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Details On Android, a Label with LineBreakMode="WordWrap" placed inside a width-constrained layout may clip text on the right side instead of wrapping correctly. This behavior occurs depending on the combination of Flow ### Root Cause PR dotnet#33281 introduced a GetDesiredSize() override in LabelHandler.Android.cs to address issue dotnet#31782, where WordWrap labels reported the full width constraint instead of the actual text width. The fix narrowed the measured width by computing the longest wrapped line and returning that value as the desired width. However, narrowing the width without proper verification could cause additional line wrapping, leading to text clipping or incorrect layout, especially in RTL or bidirectional text scenarios. Later, PR dotnet#34279 restricted this logic to run only when the MaxLines property is explicitly set. As a result, when MaxLines is not defined, the width-narrowing verification is skipped, which can again cause incorrect wrapping and text clipping in certain alignment and layout configurations. ### Description of Change Improved the logic in LabelHandler.Android.cs so that when measuring a Label's desired size, the code now always checks if narrowing the width would cause the text to wrap into more lines than the original measurement. This prevents truncation or clipping of text. ### Validated the behaviour in the following platforms - [x] Android - [ ] Windows - [ ] iOS - [ ] Mac ### Issues Fixed: Fixes dotnet#34459 ### Screenshots | Before | After | |---------|--------| | <img height=600 width=300 src="https://github.com/user-attachments/assets/44222872-0093-4a97-af81-49b0e1be4aab"> | <img height=600 width=300 src="https://github.com/user-attachments/assets/27361bd2-8922-4b83-8d70-3d24b27fe9e1"> |
…t/bottom edge overflows (dotnet#34385) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Root Cause: Two bugs in the Stretch.None branch: 1. Only left/top edges were checked — right/bottom overflow was ignored 2. Translation formula pathBounds.X + viewBounds.Left - pathBounds.Left simplifies to just viewBounds.Left (a fixed absolute, not a relative offset), causing both mirror-image lines to receive the same translateX What NOT to Do: - ❌ Don't use pathBounds.X + viewBounds.Left - pathBounds.Left — simplifies to an absolute position - ❌ Don't check only left/top — reversed-coordinate paths overflow right/bottom - ❌ Don't center paths for Stretch.None — breaks semantics for paths already within bounds ### Description of Change <!-- Enter description of the fix in this section --> This pull request addresses an issue where line coordinates were not computed correctly in certain scenarios, specifically impacting the symmetry of rendered lines. The changes include a fix to the path transformation logic for shapes with `Stretch.None`, and the addition of both a manual test case and an automated UI test to verify the fix. **Bug fix: Path transformation for `Stretch.None`** * Improved the logic in `TransformPathForBounds` in `Shape.cs` to correctly translate paths within view bounds for shapes with `Stretch.None`, ensuring that lines are properly aligned and symmetric when rendered. **Testing and validation:** * Added a new manual test page `Issue11404` in the test host app to visually verify that two thick red lines form a symmetric "V" shape and programmatically check the symmetry of their computed bounds. * Introduced an automated UI test for `Issue11404` to assert that the rendered lines are symmetric by checking the computed result label, ensuring the fix is validated across platforms. ### Issues Fixed <!-- Please make sure that there is a bug logged for the issue being fixed. The bug should describe the problem and how to reproduce it. --> Fixes dotnet#11404 Fixes dotnet#26961 <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. --> ### Output | Before | After | |--|--| | <img width="300" height="600" alt="11404_Before" src="https://github.com/user-attachments/assets/9f8f54cf-5aaa-4b81-b620-6c67fc0b5a5d" /> | <img width="300" height="600" alt="11404_After" src="https://github.com/user-attachments/assets/3075ec90-1ce6-4496-b9e9-f99267346766" /> | --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…nal layout (dotnet#33639) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> When using CV2, `UICollectionViewCompositionalLayout` relies on an internal `UIScrollView`. Scrollbar visibility were applied only to the `UICollectionView`, but for the scrollbars to render correctly, the visibility must also be updated on the internal scroll view. - Updated the Extension methods in `CollectionViewExtensions.cs` to also update the scroll indicator visibility on the internal `UIScrollView` when a `UICollectionViewCompositionalLayout` is used. - Added retry logic to apply the update when the internal scroll view is not yet created. <!-- Enter description of the fix in this section --> The following macOS snapshots were updated as part of this PR: - `CarouselViewShouldScrollToRightPosition.png` (Issue dotnet#7144) - `IndicatorViewWithTemplatedIcon.png` (Issue dotnet#17283) These changes are intentional because, after this PR, the scrollbars are now rendered on macOS as expected. Previously, they were not visible due to the underlying issue. With the fix in place, the visual output has been corrected, and the regenerated snapshots reflect this expected behavior rather than a regression. <!-- Please make sure that there is a bug logged for the issue being fixed. The bug should describe the problem and how to reproduce it. --> Fixes dotnet#29390 - [ ] Windows - [ ] Android - [x] iOS - [x] MacCatalyst | Before Issue Fix | After Issue Fix | |----------|----------| | <video src="https://github.com/user-attachments/assets/5367d48b-3bff-4334-9e90-f6d66e2e9cdc"> | <video src="https://github.com/user-attachments/assets/f6cd0bc8-d7fa-4a7c-b4ce-4fbd785d44a5"> | <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. -->
…e behavior as BackgroundColor Transparent (dotnet#32245) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Details - Setting a modal page’s background to transparent does not produce the same result as using BackgroundColor="Transparent". ### Root Cause of the issue - In the ControlsModalWrapper, only the BackgroundColor property is checked — the Background property isn’t considered. Therefore, the page continues to use the UIModalPresentationStyle.FullScreen mode. ### Description of Change **Transparency detection improvements:** * Added internal static method `Brush.HasTransparency(Brush background)` to reliably detect transparency in both `SolidColorBrush` and `GradientBrush` types. **Modal presentation logic update:** * Updated `ControlsModalWrapper` constructor to use `Brush.HasTransparency ` for determining if a modal page should use `OverFullScreen` presentation style, ensuring correct handling of transparent backgrounds set via the `Background` property. <!-- Enter description of the fix in this section --> ### Issues Fixed <!-- Please make sure that there is a bug logged for the issue being fixed. The bug should describe the problem and how to reproduce it. --> Fixes dotnet#22769 ### Tested the behaviour in the following platforms - [x] - Windows - [x] - Android - [x] - iOS - [x] - Mac ### Output | Before | After | |----------|----------| | <video src="https://github.com/user-attachments/assets/f90704db-9d8f-4667-9986-59a9c741531d"> | <video src="https://github.com/user-attachments/assets/81200022-417d-4918-818b-55046add231f"> | <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. -->
…otnet#32864) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change Fixes issue dotnet#32356 where images with LogicalName containing path separators e.g., "challenges/groceries.png") failed to load on Windows platform. ### Root Cause The Windows implementation in FileImageSourceService.Windows.cs was directly concatenating the filename to the ms-appx:/// URI without extracting the filename from paths containing separators. ### Fix details Extract the filename using Path.GetFileName() before creating the URI, aligning Windows behavior with other platforms. Fixes dotnet#32356 ---------
<!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! In src/Core/src/Layouts/Flex.cs, inside the layout_item function, the layout.reverse2 block that adjusts the cross-axis position trackers (pos, old_pos) was executed **before** children were repositioned within their line. This meant children were placed using already-decremented reference points, producing incorrect spacing when AlignContent is SpaceAround, SpaceBetween, or SpaceEvenly with FlexWrap.Reverse. Moved the layout.reverse2 adjustment block in Flex.cs from **before** to **after** the child-positioning loop within each line iteration. Children are now positioned using the correct (original) pos and old_pos values, after which the position trackers are decremented for the next line. Changed file: src/Core/src/Layouts/Flex.cs — layout_item function, cross-axis line positioning loop. **HostApp page:** src/Controls/tests/TestCases.HostApp/Issues/Issue31565.cs Creates a FlexLayout with Wrap = FlexWrap.Reverse and 7 children. Buttons let the user toggle AlignContent between SpaceAround, SpaceBetween, and SpaceEvenly. **UI tests**: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue31565.cs Three screenshot-based tests (one per AlignContent value), with snapshot baselines for Android, iOS, Windows, and Mac. Fixes dotnet#31565 - [x] Android - [x] Windows - [x] iOS - [x] Mac | Before Issue Fix | After Issue Fix | |----------|----------| | <video src="https://github.com/user-attachments/assets/80a8f5ff-e827-4585-a1a9-4a83bac55d68"> | <video src="https://github.com/user-attachments/assets/573cfefd-a1ac-40fb-bb10-941ecb01500e"> |
…cing is set (dotnet#32135) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Issue Details - CurrentItem does not update when ItemSpacing is set. ### Root Cause - When ItemSpacing is set on a CarouselView using CV2 (CarouselViewHandler2), the page calculation logic was only considering the container size but ignoring the additional space consumed by ItemSpacing. ### Description of Change - Updated the page index calculation in LayoutFactory2.cs to include ItemSpacing when determining the current page in the carousel layout. This ensures that CurrentItem updates correctly when spacing is present. ### Issues Fixed Fixes dotnet#32048 ### Validated the behaviour in the following platforms - [x] Windows - [x] Android - [x] iOS - [x] Mac ### Output | Before | After | |----------|----------| | <video src="https://github.com/user-attachments/assets/81a4529b-049b-4662-be87-90a83cd94a70"> | <video src="https://github.com/user-attachments/assets/9448e421-a065-44aa-846f-3d0af0696de0"> |
…ound in ItemsSource (dotnet#32141) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Issue Details - When a current item is set to a value that doesn't exist in the CarouselView's items source, the carousel incorrectly scrolls to the last item in a looped carousel. ### Root Cause CarouselViewHandler1 : - When CarouselView.CurrentItem is set to an item that is not present in the ItemsSource, ItemsSource.GetIndexForItem(invalidItem) returns -1, indicating that the item was not found. This -1 value is then passed through several methods: UpdateFromCurrentItem() calls ScrollToPosition(-1, currentPosition, animate), which triggers CarouselView.ScrollTo(-1, ...). In loop mode, this leads to CarouselViewHandler.ScrollToRequested being invoked with args.Index = -1. The handler then calls GetScrollToIndexPath(-1), which in turn invokes CarouselViewLoopManager.GetGoToIndex(collectionView, -1). Inside GetGoToIndex, arithmetic operations are performed on the invalid index, causing -1 to be treated as a valid position. As a result, the UICollectionView scrolls to this calculated physical position, which corresponds to the last logical item, producing unintended scroll behavior. CarouselViewHandler2 : - When CurrentItem is not found in ItemsSource, GetIndexForItem returns -1; in loop mode, CarouselViewLoopManager.GetCorrectedIndexPathFromIndex(-1) adds 1, incorrectly converting it to 0, which results in an unintended scroll to the last duplicated item. ### Description of Change - Added a check in ScrollToPosition methods in both CarouselViewController.cs and CarouselViewController2.cs to return early if goToPosition is less than zero, preventing unwanted scrolling when the target item is invalid. - **NOTE** : This [PR](dotnet#31275) resolves the issue of incorrect scrolling in loop mode when CurrentItem is not found in the ItemsSource, on Android. ### Issues Fixed Fixes dotnet#32139 ### Validated the behaviour in the following platforms - [x] Windows - [x] Android - [x] iOS - [x] Mac ### Output | Before | After | |----------|----------| | <video src="https://github.com/user-attachments/assets/48c77f1b-0819-4717-8cf6-68873f82ec1d"> | <video src="https://github.com/user-attachments/assets/1a667869-d79b-48fd-bc05-7ae3bd16a654"> |
…indicators (dotnet#31775) ### Root Cause On Android, the `MauiPageControl` did not provide proper accessibility support for its indicator items. Each `ImageView` lacked meaningful accessibility configuration, causing `TalkBack` to either skip `indicators` entirely or announce them generically as “`button`” without context. ### Description of Change Accessibility support for indicator items in `MauiPageControl` was improved to provide meaningful TalkBack announcements. Each indicator `ImageView` is now configured with `ImportantForAccessibility = Yes` and a shared static `IndicatorAccessibilityDelegate` that overrides ClassName to `android.view.View`, preventing TalkBack from announcing indicators as generic “buttons”. Dynamic content descriptions are set via `UpdateIndicatorAccessibility` using Android string resources (`strings.xml`), announcing “Item 2 of 5, selected” for the active indicator and “Item 2 of 5” for inactive ones. The selected indicator is marked Clickable = false to suppress TalkBack’s “double tap to activate” hint, with `SetupIndicatorAccessibility` called after `SetOnClickListener` to avoid overriding the clickable state. Descriptions are refreshed on every carousel swipe through `UpdatePosition`, ensuring announcements remain accurate as the user navigates. ### Issues Fixed Fixes dotnet#31446 Tested the behaviour in the following platforms - [x] Android - [ ] Windows - [ ] iOS - [ ] Mac **Note:** The device test case was added only for Android, since this issue fix was specific to the Android platform. ### Output Video Before Issue Fix | After Issue Fix | |----------|----------| |<video width="40" height="60" alt="Before Fix" src="https://github.com/user-attachments/assets/c1530353-53c0-4736-b93a-4aecaf9bb493">|<video width="50" height="40" alt="After Fix" src="https://github.com/user-attachments/assets/ccecfde6-8c5e-4ea7-a5f3-2388813af662">|
… control buttons in TitleBar (dotnet#30400) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Details TitleBar doesn't properly handle right-to-left (RTL) layout direction, causing incorrect content alignment, overlapped with system buttons ### Description of Change <!-- Enter description of the fix in this section --> Based on the FlowDirection, updated the TitleBar to apply appropriate Margin values to the content grid for both Windows and Mac platforms using visual states. This ensures correct alignment in both LTR and RTL layouts, ### Issues Fixed <!-- Please make sure that there is a bug logged for the issue being fixed. The bug should describe the problem and how to reproduce it. --> Fixes dotnet#30399 <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. --> **Tested the behavior in the following platforms.** - [ ] Android - [x] Windows - [ ] iOS - [x] Mac | Before | After | |---------|--------| | **Mac**<br> <video src="https://github.com/user-attachments/assets/36087c70-547f-429e-a7dd-d5950107b80f" width="600" height="300"> | **Mac**<br> <video src="https://github.com/user-attachments/assets/2bcb9b79-b3be-4ba6-9d1a-aac5aef42070" width="600" height="300"> |
…lt AutoSize for Height and Width after reset (dotnet#31648) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Details: When a BoxView inside an AbsoluteLayout is defined with AutoSize for width and height, and later its bounds are changed to explicit values and then reset back to AutoSize, the reset fails on iOS. ### Root Cause On iOS/macOS, when a BoxView (or any Shape) inside an AbsoluteLayout is reset back to AutoSize, the control remains visible with its previous explicit bounds. The issue occurs because the Bounds property in PlatformGraphicsView retains the previous size. During measure, AbsoluteLayout queries the child’s desired size. Since PlatformGraphicsView.Bounds still holds the old value, the shape continues to visible. ### Description of Change Override GetDesiredSize in ShapeViewHandler.iOS.When VirtualView.Width or VirtualView.Height is NaN, set the corresponding dimension in the returned Size to 0. This ensures that shapes like BoxView collapse correctly when reset to AutoSize, matching Android behavior. Validated the behavior in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Reference https://github.com/dotnet/maui/blob/3273d2bf7b48208968cec958cd3eb01690c777ba/src/Core/src/Handlers/ShapeView/ShapeViewHandler.Android.cs#L64-L78 ### Issues Fixed: Fixes dotnet#31496 ### Screenshots | Before | After | |---------|--------| | <video src="https://github.com/user-attachments/assets/e16adeac-1f37-4d80-82ae-b36b17983237"> | <video src="https://github.com/user-attachments/assets/3c1dfb19-24e4-4559-b03b-13946c5662ba"> | --------- Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
> [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue details FlyoutPage on Windows did not update its layout when the CollapseStyle property changed at runtime. ### Description of Change <!-- Enter description of the fix in this section --> This update enables dynamic support for the CollapseStyle property in FlyoutPage on Windows. It allows the flyout pane to update at runtime when the property changes, ### Issues Fixed <!-- Please make sure that there is a bug logged for the issue being fixed. The bug should describe the problem and how to reproduce it. --> Fixes dotnet#18200 <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. --> **Tested the behavior in the following platforms.** - [x] Windows | Before | After | |---------|--------| | **Windows**<br> <video src="https://github.com/user-attachments/assets/9d7844d7-af65-465a-abb3-b611290afe1f" width="400" height="250"> |**Windows**<br> <video src="https://github.com/user-attachments/assets/2edd0934-c369-4dda-8269-e22291769c2e" width="400" height="250"> |
…cCatalyst platform. (dotnet#30067) ### Issue Details: Tapping outside the Picker does not dismiss it on iOS and Mac, whereas it works as expected on Android and Windows. ### Root Cause: The touch handling for taps outside the picker was not implemented, which is why the picker was not being dismissed as expected on iOS and Mac platform. ### Description of Change: To resolve this issue, a tap gesture recognizer was added to the window containing the Picker. This allows the system to detect taps outside the Picker and dismiss it appropriately. The gesture recognizer is added during the OnStarted event and properly removed and disposed of in the OnEnded event and Disconnect methods. This implementation has been applied and successfully verified on both iOS and macOS platforms. **Tested the behavior in the following platforms.** - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Reference: N/A ### Issues Fixed: Fixes dotnet#19168 ### Screenshots | Before | After | |---------|--------| | <Video src="https://github.com/user-attachments/assets/71127543-736a-4268-a506-9493e24dc3d9"> | <Video src="https://github.com/user-attachments/assets/17cf77c4-df5a-4d71-ba40-25012be5e363"> |
…interpreted as a password input (dotnet#29344) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Issue Details - While setting an Entry's Keyboard to Date causes it to be interpreted as a password input. ### Root Cause - While using a bitwise OR operation to combine InputScopeNameValue's DateDayNumber, DateMonthNumber, and DateYear results in the value 31, which coincides with the enum value for Password, potentially causing the input scope to be incorrectly interpreted as a password field. ### Description of change - The InputScopeNameValue enum is not marked with the [Flags] attribute, and its values are not powers of two, so it is not designed for use with bitwise OR operations. Therefore, assigned only one relevant enum value for each keyboard type. Specifically, assigned InputScopeNameValue.DateDayNumber for Keyboard.Date and InputScopeNameValue.TimeHour for Keyboard.Time, ensuring proper behavior for these keyboard types. ### Issues Fixed Fixes dotnet#28975 ### Validated the behaviour in the following platforms - [x] Windows - [x] Android - [x] iOS - [x] Mac ### Output | Before | After | |----------|----------| | <video src="https://github.com/user-attachments/assets/075f5198-4551-42ad-8061-6c7a73cd1c4d"> | <video src="https://github.com/user-attachments/assets/9d5b4880-21db-4031-929d-06eeb3a10d9b"> |
…otnet#28353) ### Issue Details: The graphics view can be drawn outside the canvas ### Root Cause: There was no restriction on where the drawable could be drawn. As a result, the drawable was drawn outside the canvas bounds. ### Description of Change: Added a clip rect value to restrict the drawable to draw only within the canvas bounds. Validated the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Issues Fixed Fixes dotnet#20834 ### Output | Before | After | | ------ | ----- | |<video src="https://github.com/user-attachments/assets/95832794-db47-4582-b0dc-1caf7035f868">| <video src="https://github.com/user-attachments/assets/954659db-6344-47ee-bc94-eece8580693c">| --------- Co-authored-by: Matthew Leibowitz <mattleibow@live.com>
…otnet#34950) ### Description of Change Fixes the `FlyoutHeaderScroll` device test regression introduced by PR dotnet#28713. After PR dotnet#28713 added `IPlatformMeasureInvalidationController` to `ShellFlyoutHeaderContainer`, the header height after scrolling may include the safe area margin (~44px) depending on the content type. **Changes (test only, no core code changes):** - Height assertion: accept header height between `headerRequestedHeight` and `headerRequestedHeight + safeAreaTop` - Scroll position assertion: use `scrolledBox.Height` instead of hardcoded `headerRequestedHeight` - Fix typos in assertion messages ### Issues Fixed Fixes FlyoutHeaderScroll device test regression from dotnet#28713 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…for HTML labels (dotnet#34934) (dotnet#34951) ### Description of Change Ports the test fix from PR dotnet#34934 (inflight/current) to inflight/candidate. PR dotnet#31202 changed the Label mapper conditions from `!IsPlainText(label)` to `label.HasFormattedTextSpans` for `MapLineHeight`, `MapTextDecorations`, and `MapCharacterSpacing`. This correctly enables these properties to be applied to HTML labels. However, the test expectations for `label4` (an HTML label with `CharacterSpacing=5`, `LineHeight=1.5`, `TextDecorations=Underline`) were not updated. **Fix:** Update expected values for label4 from `(0, 0, None)` to `(5, 1.5, Underline)`. ### Issues Fixed Fixes CharacterSpacingWithLineHeightWithTextDecorationsWorksCorrectly device test regression from dotnet#31202 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…on candidate branch (dotnet#34996) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Root Cause During CarouselView startup on Android, `UpdateFromPosition` runs before the carousel is fully initialized (`_initialized = false`). It sets `_gotoPosition` during an initial scroll attempt, but since the layout is not ready, the scroll never completes. This leaves `_gotoPosition` stuck at a non-negative value. Earlier, this was unintentionally handled by an unconditional `_gotoPosition = -1` in `UpdateFromCurrentItem`, which cleared the stale state. PR dotnet#34570 removed that line (to avoid breaking the guard during animations for dotnet#29544), exposing the issue. As a result, `_gotoPosition` remains stuck, causing all subsequent `UpdateFromPosition` calls to fail the `_gotoPosition == -1` check and skip scrolling. This leads to timeouts in tests like `Issue23291` and `Issue29216`, as the carousel never moves to the requested position. ### Description of Change Updated the guard condition in `UpdateFromPosition` by applying the `_initialized` check only to the `_gotoPosition` assignment, ensuring it is set only after initialization while leaving the rest of the logic unaffected. This prevents premature or stale `_gotoPosition` values during startup and preserves the existing scroll behavior, keeping the change safe. ### Issues Fixed Fixes regression introduced by dotnet#34570 : `Issue23291Test` `Issue29216CarouselViewScrollingIssue on Candidate branch`. Tested the behaviour in the following platforms - [x] Android - [ ] Windows - [ ] iOS - [ ] Mac
…ps test failure regression (dotnet#35000) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Issue Description Fixes a regression introduced by PR dotnet#31867, where all grouped CollectionView drag-and-drop reorder tests fail on Android — most visibly `VerifyFlowDirectionRTLCanReorderItemsTrueWithCanMixGroups`. ### Root cause PR dotnet#31867 changed SimpleItemTouchHelperCallback.OnMove from checking the target view type to checking the source view type, so that items can be dropped onto empty group headers. The side effect: OnItemMove can now be called with a non-empty group's GroupHeader as toPosition. When dragging an item forward past the next group's header (e.g., "Banana" toward "Potato"), OnItemMove fires with the GroupHeader as target and prematurely inserts the item mid-gesture, before the drop is intentional. LTR tests pass accidentally — the premature insertion moves the item downward, so the newY > initialY assertion coincidentally passes. RTL test fails — the mid-gesture NotifyItemMoved causes a layout pass that makes ItemTouchHelper's internal gesture offset stale in RTL coordinate space, aborting the drag and leaving newY == initialY. ### Description of Change Added a guard in `ReorderableItemsViewAdapter.OnItemMove:` when the drag targets a non-empty group's header (toIndex == 0, HasHeader == true, Count > 0), return false immediately — no data mutation, drag continues cleanly. Empty group headers are still allowed as drop targets, preserving the original PR dotnet#31867 intent. ### Issues Fixed - Regression introduced by PR dotnet#31867 - **Resolved test case:** VerifyFlowDirectionRTLCanReorderItemsTrueWithCanMixGroups ### Output | Before | After | |----------|----------| | <img src="https://github.com/user-attachments/assets/e61cb83d-d631-4a75-9715-85366cad9593"> | <img src="https://github.com/user-attachments/assets/9f10fd8b-f173-426d-ae54-79daa82beb56">|
…ndidate branch (dotnet#35013) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Root Cause Applying `ClipBounds = Rect(0, 0, width, height)` constrained the WebView strictly to its layout bounds, preventing shadows (rendered by the parent `WrapperView`) from drawing outside the view. This clipped the shadow and caused UI test failures due to visual mismatch with baseline snapshots. ### Description of Change Updated logic to set `ClipBounds = null` once the view has a valid size, restoring default Android behavior where layout bounds (not `ClipBounds`) control rendering. - Constructor still applies an empty clip to prevent pre-layout full-screen flash - Zero-size scenarios reapply the empty clip to maintain correctness - Aligns with existing handling in `LayoutViewGroup` [Ref](https://github.com/praveenkumarkarunanithi/maui/blob/main/src/Core/src/Platform/Android/LayoutViewGroup.cs#L161) when clipping is disabled ### Issues Fixed Fixes regression introduced by dotnet#33207 : `VerifyHybridWebViewWithShadow` on Candidate branch. Tested the behaviour in the following platforms - [x] Android - [ ] Windows - [ ] iOS - [ ] Mac
…#35012) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Details: - [SwipeViewShouldNotClose]UI test (Issue29086) fails with [System.TimeoutException: Timed out waiting for no element] on Android after PR dotnet#24275 was merged. ### Root Cause: - PR dotnet#24275 added a check in [MauiSwipeView.ShouldInterceptTouch()](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html) to prevent taps on an open SwipeView from propagating to content children: - When [_isOpen] is true, [OnInterceptTouchEvent]returns true, which causes Android to steal all touch events from children — including buttons inside SwipeItemView controls. This breaks the Issue29086 scenario where buttons inside revealed swipe items (e.g., AddButton1) need to receive taps to fire their [Command]and update the AutomationId. ### Description of Change Touch event handling improvement: * Updated `ShouldInterceptTouch(MotionEvent? e)` in `MauiSwipeView.cs` to only intercept touches when the swipe view is open and the touch is within the content area, enhancing gesture accuracy. ### Issues Fixed <!-- Please make sure that there is a bug logged for the issue being fixed. The bug should describe the problem and how to reproduce it. --> - Regression introduced by PR dotnet#24275 - Resolved test case: SwipeViewShouldNotClose | Before | After | |----------|----------| | <img src="https://github.com/user-attachments/assets/4d3f99b6-00f7-4114-be7f-92a4821a9078"> | <img src="https://github.com/user-attachments/assets/8bbdc3d2-bf70-4a6f-9652-fea8601d06ab"> | <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. -->
…h Candidate (dotnet#35028) <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue details: PR dotnet#24610 switched collection change wiring to a weak event proxy to fix a memory leak, but the callback delegate was not strongly retained. As a result, GC could collect the delegate, so CollectionChanged notifications stopped reaching the Android items pipeline, which caused the CarouselView and CollectionView test failures. ### Description of Change <!-- Enter description of the fix in this section --> In MarshalingObservableCollection.cs, added a strong field to hold the NotifyCollectionChangedEventHandler delegate. In the constructor, assigned that field once and passed the stored delegate to WeakNotifyCollectionChangedProxy instead of passing a temporary method-group delegate. Kept existing dispose/unsubscribe behavior so the leak fix remains intact while notifications continue to fire correctly. ### Failure test cases **CarouselView tests fails** * VerifyCarouselViewWithKeepItemInView * VerifyCarouselViewWithKeepItemInViewAndPreviousPosition * VerifyCarouselViewWithKeepItemInViewAndCurrentPosition * VerifyCarouselViewWithCurrentPosition * VerifyCarouselViewWithKeepLastItemInViewAndCurrentPosition * AddItemsToCarouselViewWorks **CollectionView test fails** * VerifyModelItemsObservableCollectionWhenAddIndexAtItems * VerifyFlowDirectionRTLAndKeepLastItemInViewWithObservableListWhenVerticalGrid * VerifyFlowDirectionLTRAndKeepLastItemInViewWithObservableListWhenVerticalGrid * VerifyKeepLastItemInViewWithObservableListWhenVerticalGrid * VerifyKeepLastItemInViewWithObservableList * VerifyFlowDirectionLTRAndKeepLastItemInViewWithObservableListWhenHorizontalList * VerifyFlowDirectionRTLAndKeepLastItemInViewWithObservableListWhenHorizontalList * VerifyFlowDirectionRTLAndKee **Device Test fails** * CollectionViewCanSizeToContent
…tnet#35024) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ## Description PR dotnet#34228 added public `IAlertManager` and `IAlertManagerSubscription` interfaces, but it was merged into `inflight/current` when the public API change likely should have gone through `main` first. This PR reverts the **public API surface** of those changes on `inflight/candidate`, while keeping the refactor (the interfaces, the DI wiring, the `AlertManager : IAlertManager` split) in place. The interfaces are now marked `internal` so no new public API is shipped from the inflight branches, and the `PublicAPI.Unshipped.txt` files are restored to their pre-dotnet#34228 state. ### Changes - Mark `IAlertManager` as `internal` - Mark `IAlertManagerSubscription` as `internal` - Remove the corresponding entries from all 7 `PublicAPI.Unshipped.txt` files (net, net-android, net-ios, net-maccatalyst, net-tizen, net-windows, netstandard) All existing consumers (`AlertManager`, `Window`, `AlertManagerTests`) are internal to the `Controls.Core` assembly and/or have `InternalsVisibleTo`, so no other code changes are needed. ### Follow-up The public API change can be re-introduced via a separate PR targeting `main` if/when desired. Targets: `inflight/candidate` Related: dotnet#34228 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…tnet#34959) This pull request updates test cases for carousel and label tap behavior to improve reliability and accuracy. The main changes include improving tap detection in label tests, updating the carousel view bounce test to use a new button for navigation, and adding a new UI element to the carousel view test page. **Test improvements:** * In the label tap test (`Issue21837.cs`), taps are now performed at specific coordinates near the leading edge of each label's text to ensure accurate hit detection, especially when label widths exceed the rendered text width. **Carousel view test updates:** * The carousel bounce test (`Issue29261.cs`) now uses a newly added "Go to Last" button to reliably set the carousel to the last position before testing bounce behavior, replacing multiple swipe actions with a button tap and scroll gestures. * The test page for the carousel view (`Issue29261.cs`) adds a "Go to Last" button (`goToLastButton`) to facilitate direct navigation to the last carousel item. **Test cleanup:** * Removes unnecessary conditional compilation and comments related to unsupported swipe actions on Catalyst, simplifying test code. **Test image resaving:** * Resaved the valid images on the Android, iOS and macOS platforms **Fixes:** dotnet#34885 --------- Co-authored-by: NafeelaNazhir <nafeela.nazhirhussain@syncfusion.com> Co-authored-by: devanathan-vaithiyanathan <114395405+devanathan-vaithiyanathan@users.noreply.github.com> Co-authored-by: HarishKumarSF4517 <harish.kumar@syncfusion.com> Co-authored-by: Subhiksha Chandrasekaran <subhiksha.c@syncfusion.com> Co-authored-by: LogishaSelvarajSF4525 <logisha.selvaraj@syncfusion.com>
Contributor
|
Hey there @@TamilarasanSF4853! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed. |
dotnet-policy-service
Bot
added
the
partner/syncfusion
…ranch (dotnet#35041) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Root Cause During CarouselView startup, `UpdateFromPosition` triggers an initial animated scroll to center the first item. In this flow, `_gotoPosition` is set, but `CarouselViewScrolled` exits early (`!_initialized`), so `UpdatePosition` never clears it. This leaves `_gotoPosition` stuck at `0`, blocking subsequent programmatic scrolls. When `Position = 1` is later set (Issue29216), the guard condition (`_gotoPosition == -1`) fails, preventing the scroll. ### Description of Change Updated the animated scroll path to assign `_gotoPosition` only after initialization. This aligns it with the non-animated fix - [34996](dotnet#34996), preserves startup centering behavior, and ensures `_gotoPosition` is set only when it can be properly cleared. ### Issues Fixed Fixes regression introduced by dotnet#34570 : `Issue29216CarouselViewScrollingIssue on Candidate branch`. Tested the behaviour in the following platforms - [x] Android - [ ] Windows - [ ] iOS - [ ] Mac
…n on candidate branch (dotnet#35057) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Root Cause The previous regression fix (PR dotnet#35013) set `ClipBounds = null` unconditionally in `OnSizeChanged` to resolve shadow clipping. While effective for shadows, this reintroduced the original full-screen flash issue (dotnet#31475) on slower devices. The underlying issue is that `ClipBounds = null` removes GPU-level rendering constraints. On slower devices, the hardware-accelerated WebView compositor renders a frame at full-screen size before Android layout bounds are enforced. Debug analysis showed that when Shadow/Border/Clip is applied, MAUI wraps the WebView inside a `WrapperView`. In this scenario, the wrapper constrains rendering, making `ClipBounds = null` safe. Without decorations, the WebView is hosted directly under `LayoutViewGroup` (with `ClipChildren = false`), requiring explicit bounds to prevent the flash. ### Description of Change Introduced a `UpdateClipBounds` method to dynamically determine the correct clipping strategy based on the parent: * **Parent is WrapperView (decorations applied):** Sets `ClipBounds = null` to allow shadow and visual overflow * **Parent is not WrapperView (no decorations):** Sets exact bounds to prevent full-screen flash on slower devices * **Zero size:** Applies empty bounds to block rendering when the view is collapsed Additionally, added an `OnAttachedToWindow` override to re-evaluate `ClipBounds` during runtime re-parenting (e.g., when shadow is toggled). This is required because re-parenting does not trigger `OnSizeChanged`. This approach aligns with existing MAUI patterns (e.g., `ContentViewGroup` handling parent checks in similar lifecycle hooks). ### Issues Fixed Fixes regression introduced by dotnet#35013 : `WebViewBackgroundColorShouldBeApplied` on Candidate branch. Tested the behaviour in the following platforms - [x] Android - [ ] Windows - [ ] iOS - [ ] Mac
TamilarasanSF4853
force-pushed
the
candidate-fix-34885-2
branch
from
f84f84c to
5dcfeab
Compare
Contributor
|
/azp run maui-pr-uitests , maui-pr-devicetests |
|
Azure Pipelines successfully started running 2 pipeline(s). |
This was referenced Apr 21, 2026
Open
Ahamed-Ali
force-pushed
the
inflight/candidate
branch
from
de98843 to
e6b2351
Compare
Contributor
|
closed this PR as duplicate |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request makes a small change to the test case for Issue 29544. The test now uses the
CarouselView2control instead of the originalCarouselViewcontrol inIssue29544.cs.Fixes: #34885