Improve performance on PropertyChanged#35303
Closed
pictos wants to merge 131 commits into
Closed
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>
This was referenced May 16, 2026
Contributor
|
@pictos what do you think about the @AdamEssenmacher's comment? |
Contributor
Author
|
Yes, it does. It will be handled on a separated PR |
This was referenced May 20, 2026
Contributor
|
/review -b feature/refactor-copilot-yml |
This was referenced May 25, 2026
Contributor
|
/review -b feature/refactor-copilot-yml -p ios |
Contributor
Author
|
Close this one, since it case will be handled in separated PRs. The PRs will reference this PR and root issue |
kubaflo
pushed a commit
that referenced
this pull request
Jun 14, 2026
<!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Description of Change <!-- Enter description of the fix in this section --> This is a follow up from #35303, that implements the `BooleanBoxes` class and use inside the `Control` project [Use the same solution that the WPF team uses](https://github.com/dotnet/wpf/blob/b325a186ebcead7fddfde43c118f6a807397de35/src/Microsoft.DotNet.Wpf/src/WindowsBase/MS/Internal/KnownBoxes.cs#L10), cache the boxed `true` and `false` values, and use it instead of boxing a new boolean on every operation. ### 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. --> Relates with #35302 <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. --> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Pedro Jesus <pedrojesus@Pedros-MacBook-Pro.local>
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
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.
Issues Fixed
Fixes #35302
Description of Change
Summary
This PR reduces allocation pressure in property-change paths by reusing frequently repeated boxed/brush values instead of creating new objects on each update.
The goal is to improve hot UI update scenarios where controls receive many repeated property sets (especially Background and bool-based properties).
During my tests, I found 3 issues.
PropertyChangedEventArgson every PropertyChanged;SolidColorBrushon everyBackgroundproperty changed.Key Changes
Respectively, the solution for each problem was:
PropertyChangedEventArgsinstances for the most common properties, only that reduces the allocation by 50%. (Also added into thePropertyChangingEventArgs)trueandfalsevalues, and use it instead of boxing a new boolean on every operation. On this PR, it was only for one property, but I'll follow up with other properties right after this gets merged.Brushvalues and reuse them. For that, I implemented a LRU Cache with a limited size of 50 (empirically chosen).Results
Comparing the Benchmark results against the
mainbranch, I found these values. (If I did everything right, including the benchmark code.)