Comparing changes

@NafeelaNazhir

…ctivities (#33805) - [x] Analyze the issue and understand the crash from stack trace - [x] Review PR #29780 fix pattern for destroyed activity context check - [x] Add context destruction check in `PlatformInterop.loadImageFromFont(Context...)` method - [x] Add context destruction check in other `PlatformInterop` methods that use `Glide.with(context)`: - [x] `loadImageFromFile(Context...)` - [x] `loadImageFromUri(Context...)` - [x] `loadImageFromStream(Context...)` - [x] Verify changes compile successfully - [x] Move `isContextDestroyed` and `getActivity` methods to `PlatformInterop` and have `MauiCustomTarget` call them - [x] Run code review - [x] Run CodeQL security scan - [x] Final verification  <details> <summary>Original prompt</summary> ---- *This section details on the original issue you should resolve* <issue_title>java.lang.IllegalArgumentException: You cannot start a load for a destroyed activity - glide</issue_title> <issue_description>### Description Random issue that I can not reproduce but happening on a small subset of devices according to firebase I believe a previously closed issue maybe the same thing happening: #17549 ### Steps to Reproduce No enough information to say at this point. ### Link to public reproduction project repository _No response_ ### Version with bug 9.0.70 SR7 ### Is this a regression from previous behavior? Yes, this used to work in .NET MAUI ### Last version that worked well 7.0.92 ### Affected platforms Android ### Affected platform versions Android 14 and up ### Did you find any workaround? No ### Relevant log output ```shell Fatal Exception: java.lang.RuntimeException: Unable to start activity ComponentInfo{######/crc641b109f8ad35faaaf.MainActivity}: java.lang.IllegalArgumentException: You cannot start a load for a destroyed activity at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:4206) at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:4393) at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:222) at android.app.servertransaction.TransactionExecutor.executeNonLifecycleItem(TransactionExecutor.java:133) at android.app.servertransaction.TransactionExecutor.executeTransactionItems(TransactionExecutor.java:103) at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:80) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2773) at android.os.Handler.dispatchMessage(Handler.java:109) at android.os.Looper.loopOnce(Looper.java:232) at android.os.Looper.loop(Looper.java:317) at android.app.ActivityThread.main(ActivityThread.java:8934) at java.lang.reflect.Method.invoke(Method.java) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:591) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:911) Caused by java.lang.IllegalArgumentException: You cannot start a load for a destroyed activity at com.bumptech.glide.manager.RequestManagerRetriever.assertNotDestroyed(RequestManagerRetriever.java:236) at com.bumptech.glide.manager.RequestManagerRetriever.get(RequestManagerRetriever.java:110) at com.bumptech.glide.manager.RequestManagerRetriever.get(RequestManagerRetriever.java:92) at com.bumptech.glide.Glide.with(Glide.java:545) at com.microsoft.maui.PlatformInterop.loadImageFromFont(PlatformInterop.java:394) at crc641b109f8ad35faaaf.MainActivity.n_onCreate(MainActivity.java) at crc641b109f8ad35faaaf.MainActivity.onCreate(MainActivity.java:63) at android.app.Activity.performCreate(Activity.java:9079) at android.app.Activity.performCreate(Activity.java:9057) at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1531) at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:4188) at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:4393) at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:222) at android.app.servertransaction.TransactionExecutor.executeNonLifecycleItem(TransactionExecutor.java:133) at android.app.servertransaction.TransactionExecutor.executeTransactionItems(TransactionExecutor.java:103) at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:80) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2773) at android.os.Handler.dispatchMessage(Handler.java:109) at android.os.Looper.loopOnce(Looper.java:232) at android.os.Looper.loop(Looper.java:317) at android.app.ActivityThread.main(ActivityThread.java:8934) at java.lang.reflect.Method.invoke(Method.java) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:591) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:911) ```</issue_description> <agent_instructions>Looking at the stack trace above, it looks like the problem started in `loadImageFromFont()`. This PR: * #29780 Fixes the `clear()` code path, can we apply this to the stack trace on this issue?</agent_instructions> ## Comments on the Issue (you are @copilot in this section) <comments> <comment_new><author>@NafeelaNazhir</author><body> This issue has been verified in Visual Studio Code 1.100.2 with MAUI versions (9.0.70, 9.0.60, 9.0.50, 9.0.0). It cannot be reproduced on the Android(14.0+) platform. Is there any specific configuration needed for replicate the issue? https://github.com/user-attachments/assets/2... </details>  - Fixes #29699  --- ✨ Let Copilot coding agent [set things up for you](https://github.com/dotnet/maui/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: jonathanpeppers <840039+jonathanpeppers@users.noreply.github.com>

#33818) ### Description of Change `MauiCALayer` and `StaticCAShapeLayer` crash with `EXC_BAD_ACCESS` when disposed on the finalizer thread in Release/AOT builds. The crash occurs because `Dispose()` unconditionally calls `_autosizeToSuperLayerBehavior.Detach()`, which invokes Objective-C methods on native `CALayer` objects that may have already been deallocated by UIKit. The fix wraps the `Detach()` call in `if (disposing)` to follow the standard .NET dispose pattern - only call into external/native objects during explicit disposal, not during finalization. ### Issues Fixed Fixes #33800 ### Changes - `src/Core/src/Platform/iOS/MauiCALayer.cs` - Wrap `Detach()` call in `if (disposing)` - `src/Core/src/Platform/iOS/StaticCAShapeLayer.cs` - Wrap `Detach()` call in `if (disposing)` - `src/Core/src/Platform/iOS/StaticCALayer.cs` - Wrap `Detach()` call in `if (disposing)` - `src/Core/src/Platform/iOS/StaticCAGradientLayer.cs` - Wrap `Detach()` call in `if (disposing)` ### Testing - Built MAUI from source with this fix - - Tested in a production iOS app (Release/AOT via TestFlight) - - Confirmed crashes no longer occur with the patched `Microsoft.Maui.Core`

…e Multiple times (#31487)  > [!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!  ### RootCause: UpdateTitleIcon always added a new ToolbarTitleIconImageView without checking for an existing one, causing duplicate icons when TitleIconImageSource was set multiple times. ### Description of Change  Modified UpdateTitleIcon method to check for an existing ToolbarTitleIconImageView and only add a new one if necessary, ensuring that duplicate icons are not created when the title icon is set multiple times. ### Issues Fixed  Fixes #31445 ### Tested the behavior in the following platforms - [x] Windows - [x] Android - [x] iOS - [x] Mac ### Screenshot | Before Issue Fix | After Issue Fix | |----------|----------| | <video src="https://github.com/user-attachments/assets/3aa9a70b-8db9-4e41-bd65-6790190c0fd1"> | <video src="https://github.com/user-attachments/assets/872687d1-de55-40df-8a7b-591be9c70b09"> |  --------- Co-authored-by: Shane Neuville <shneuvil@microsoft.com>

…arator (#27376)  ### Root Cause The previous behavior does not consider the application's current culture settings, causing the decimal separator to default. ### Description of Change Updated the GetDecimalSeparator method to retrieve the DecimalSeparator from the current culture using CultureInfo.CurrentCulture.NumberFormat.NumberDecimalSeparator, ensuring accurate and culture-specific formatting. ### Regarding test case I couldn't find a way to enter a comma using the numeric keyboard, so I didn't add the test case. ### Issues Fixed  Fixes #17152  **Tested the behavior in the following platforms.** - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Output Screenshot | Before | After | |---------|--------| | <video src="https://github.com/user-attachments/assets/5f5f8af1-a6ec-4e98-b989-f58c83aee933" width="320" height="240" controls></video> | <video src="https://github.com/user-attachments/assets/926d00af-91a4-499b-bbe5-091f8702182e" width="320" height="240" controls></video> |

…nvisible (#27340)  > [!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) When the Entry control is hidden, the soft keyboard remains active, and any text typed is queued and applied when the control becomes visible again. This is due to platform-specific keyboard input handling, which operates independently of control visibility. ### Root Cause (iOS) The soft keyboard remains visible and the focus persists even when the Entry control is hidden. Any text typed while the control is hidden is applied when the control becomes visible again, due to platform-specific behavior in managing focus and keyboard input. ### Description of Change Added platform-specific handling to dismiss the soft keyboard and remove focus when the Entry or Editor visibility is set to False. This prevents any new input from being queued and ensures that the keyboard is cleared when the control is hidden, restoring a clean state upon visibility restoration on Android and iOS. ### Issues Fixed Fixes #27236 **Tested the behaviour in the following platforms** - [x] Android - [ ] Windows - [x] iOS - [ ] Mac ### Output ## Android | Before | After | |---------|--------| | <video src="https://github.com/user-attachments/assets/134ecee8-c65d-4b79-8707-2e7362e35752" > | <video src="https://github.com/user-attachments/assets/fd87190f-3d4c-48d6-8aa0-1346a9d0d22f" > | ## iOS | Before | After | |---------|--------| | <video src="https://github.com/user-attachments/assets/346888ed-8d03-4859-af2c-0100dd50a597" > | <video src="https://github.com/user-attachments/assets/f3d7bc30-d070-44fb-8dd6-d7aa2de0ba43" > |

…r back button (#33531)  > [!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 This PR fixes an issue where the Shell navigation bar back button (the arrow in the top-left corner) does not trigger `OnBackButtonPressed()` on Android, while it works correctly on Windows. **Root cause:** The Shell navigation bar back button click handler (`ShellToolbarTracker.OnClick`) was calling `Page.Navigation.PopAsync()` directly without checking if the page wants to intercept the navigation via `OnBackButtonPressed()`. This differs from the system back button behavior, which properly invokes `SendBackButtonPressed()` through the Android lifecycle event system. **Fix:** Added a call to `Page?.SendBackButtonPressed()` in the `OnNavigateBack()` method before calling `PopAsync()`. If the method returns `true` (meaning the page handled the event and wants to prevent navigation), the method returns early and skips the `PopAsync()` call. **Key insight:** The navigation bar back button and system back button take completely different code paths in Shell: - **System back button:** `Activity.OnBackPressed` → `AndroidLifecycle.OnBackPressed` → `Shell` handler → `page.SendBackButtonPressed()` → `OnBackButtonPressed()` - **Navigation bar back button:** `ShellToolbarTracker.OnClick` → `OnNavigateBack()` → `PopAsync()` (directly, bypassing the check) The fix unifies these paths by ensuring both buttons check `OnBackButtonPressed()` before navigating back. **What to avoid:** Don't bypass `SendBackButtonPressed()` when programmatically popping pages in response to user navigation actions. This method is the public API contract for allowing pages to intercept back navigation. ### Issues Fixed Fixes #33523 **Verified behavior:** - ✅ System back button (hardware/gesture) continues to work correctly - ✅ Navigation bar back button now calls `OnBackButtonPressed()` - ✅ Page can prevent navigation by returning `true` - ✅ Page can allow navigation by returning `false` (default behavior) - ✅ Matches Windows platform behavior ### Testing Added UI tests that verify: 1. OnBackButtonPressed is called when tapping the Shell navigation bar back button 2. Returning `true` from OnBackButtonPressed prevents navigation 3. The behavior matches cross-platform expectations **Test files:** - `src/Controls/tests/TestCases.HostApp/Issues/Issue33523.cs` - Test page with Shell navigation - `src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33523.cs` - NUnit test verifying OnBackButtonPressed is called **Test verification:** - ❌ Tests FAIL without the fix (bug reproduced) - ✅ Tests PASS with the fix (bug resolved)

…event (#33889)  > [!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: The pointer moved event is not triggered of the PointerGestureRecognizer on Android platform. ### Root Cause: The PointerGestureRecognizer.PointerMoved event was not firing on Android because the TapAndPanGestureDetector.OnTouchEvent() method had an incomplete pattern match that was filtering out Move events. The gesture detector was only forwarding touch events to the pointer gesture handler for these actions: - MotionEventActions.Up (finger released) - MotionEventActions.Down (finger pressed) - MotionEventActions.Cancel (gesture cancelled) Missing Elements: MotionEventActions.Move (finger moved while pressed) ### Description of Change: Added MotionEventActions.Move to the pattern, the gesture detector now: - Captures move events from Android's touch system - Routes them to _pointerGestureHandler.OnTouch() - The handler processes them and fires the PointerMoved event. **Tested the behavior in the following platforms:** - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Reference: N/A ### Issues Fixed: Fixes #33690 ### Screenshots | Before | After | |---------|--------| | <Video src="https://github.com/user-attachments/assets/cb3a1f4e-b3fc-4815-bc99-fecd4ddcb158" Width="300" Height="600"> | <Video src="https://github.com/user-attachments/assets/fcea1f0c-ca82-4863-a48b-e89cd185e0bc" Width="300" Height="600"> |

…ible (#26194) ### Issue Details Editor is initially configured with VerticalTextAlignment set to End or Center and Visibility set to False, toggling the Visibility causes the vertical text alignment to unexpectedly reset to the default Start alignment. ### Root Cause: The VerticalTextAlignment value is updated during the Loaded event. However, toggling the Visibility does not re-trigger the Loaded event, resulting in the attached properties not being invalidated. ### Description of Change: Invalidate the MauiTextBox attached properties on size changes, During the Loaded or when Visibility is toggled, This ensures the VerticalTextAlignment is correctly reapplied to maintain the updated state. Fixes #25973 Validated the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Output |Before|After| |--|--| | <video src="https://github.com/user-attachments/assets/e1ae711a-c13a-48bf-b19f-883d109138a2" >| <video src="https://github.com/user-attachments/assets/3eaf105a-ff20-45fb-885b-2caed8a4576e">| --------- Co-authored-by: prakashKannanSf3972 <127308739+prakashKannanSf3972@users.noreply.github.com> Co-authored-by: BagavathiPerumal <bagavathiperumal.a@syncfusion.com>

…lues (#25749) ### Issue Detail In the Shell Navigating event, the Current and Target locations are the same. ### Root Cause The route comparison logic did not properly check the navigation state, leading to redundant route values in routeStack. ### Description of Change Updated the route validation logic to correctly compare and update routeStack. If the new route matches the existing one at the expected position, redundant elements in routeStack are removed to maintain an accurate navigation state. ### Tested the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Issues Fixed Fixes #25599 ### Screenshots | Before Issue Fix | After Issue Fix | |----------|----------| | <video width="300" height="600" src="https://github.com/user-attachments/assets/2706b3c6-f289-4eb7-9f4a-9475898bff87"> | <video width="300" height="600" src="https://github.com/user-attachments/assets/86c72f4c-f6b3-4a7c-b39c-2245fa93d885">) |

### Issue Details The ImageButton image rendered on Android was not adjusting its bounds correctly, leading to improper scaling. ### Root Cause The image button was not rendering based on its bounds value. ### Description of Change In ImageButton Android Handler, set true for SetAdjustViewBounds(), when you enable view bounds adjustment, the ImageView will automatically resize to maintain the image's aspect ratio. Validated the behavior in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Issues Fixed Fixes #25558 Fixes #14346 ### Output ScreenShot | Before | After | |---------|--------| | <img width="364" alt="Screenshot 2025-03-11 at 3 23 41 PM" src="https://github.com/user-attachments/assets/668b2bc9-be89-4f84-8ca1-c869d6a32f97" /> | <img width="366" alt="Screenshot 2025-03-11 at 3 27 32 PM" src="https://github.com/user-attachments/assets/3ef09025-a3d5-4423-bf10-78b7492660df" /> |

…to all items when IsGrouped was true for an ObservableCollection (#28886) ### Root Cause of the issue - The items in the ItemsSource collection were being cast to IEnumerable and added to the groups collection, even when they were not actually of an IEnumerable type. As a result, these individual items were incorrectly treated as groups, leading to group-related behaviors such as the display of group headers and footers. ### Description of Change - I have added a type check to ensure that only items that implement IEnumerable are added to the groups collection. If an item is not an IEnumerable, it will no longer be treated as a group, and the groups collection will remain empty in such cases. ### Issues Fixed Fixes #28827 ### Tested the behaviour in the following platforms - [x] iOS - [x] Android - [ ] Windows - [x] Mac ### Screenshot | Before Fix | After Fix | |----------|----------| | <video src="https://github.com/user-attachments/assets/5e7d5137-2e02-4cf3-8dfa-26e2ab6b197f"> | <video src="https://github.com/user-attachments/assets/97e19aa3-d379-49fe-b6ed-8ed6120019fd"> |

…ing an item DataTemplateSelector (#32349)  > [!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 * CollectionView items do not reorder correctly when using an Item DataTemplateSelector. ### Root cause * The CollectionView reorder operation did not work properly when a DataTemplateSelector was used, because the ItemsView type of the data template did not match as expected. ### Description of Change * Ignored the ItemsView type checking condition for data templates on item move when Collection view DataTemplateSelector used. Validated the behaviour in the following platforms - [x] Android - [x] Windows , - [x] iOS, - [x] MacOS ### Issues Fixed Fixes #32223 ### Output images Android |Before|After| |--|--| | <video src="https://github.com/user-attachments/assets/a1c3db67-4419-4094-8824-d4cf812283dd" >| <video src="https://github.com/user-attachments/assets/77225c95-ebc1-4300-87f2-8503935e1272">| --------- Co-authored-by: Subhiksha Chandrasekaran <subhiksha.c@syncfusion.com>

…a header in CollectionView (#30966)  > [!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, when a header is present in a CollectionView, programmatically scrolling to the last item using ScrollTo(Count - 1) does not behave as expected—it scrolls to the second-to-last item instead of the intended last item. ### Root Cause - On Android, when using a CollectionView with a header, the header occupies the first position (index 0) in the layout. However, the original implementation did not account for this offset. As a result, when scrolling to a target index (e.g., Count - 1), the presence of the header shifted the visible items by one, causing the scroll to stop one item short—typically landing on the second-to-last item instead of the intended last item. ### Description of Change - Updated DetermineTargetPosition in MauiRecyclerView.cs to account for the presence of a header in UngroupedItemsSource. - The method now adjusts the target index by adding 1 if a header is present. ### Issues Fixed Fixes #18389 ### 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/6b0ace11-8116-4318-87ed-1a3a963ebc1d"> | <video src="https://github.com/user-attachments/assets/395e538d-dbae-4123-b94e-acf0fdc68a91"> |

… ScrollView with IsVisible set to false (#29022)  > [!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 When WebView is placed inside a ScrollView (especially with `IsVisible=false`), the measurement pass can receive infinite constraints. The previous implementation in `GetDesiredSize` used `widthConstraint` and `heightConstraint` directly to initialize the `width` and `height` variables. When these constraints were infinite, the code could propagate infinite or `NaN` values into subsequent calculations, causing crashes on iOS during layout operations. The regression was introduced in PR #26629. ### Description of Change Changed `WebViewHandler.iOS.cs` to use the measured size (`size.Width` and `size.Height` from `PlatformView.SizeThatFits`) instead of the constraint values when initializing the `width` and `height` variables in `GetDesiredSize`. **Key change:** ```csharp // Before (could use infinite constraints) var width = widthConstraint; var height = heightConstraint; // After (use measured size, which is always finite) var width = size.Width; var height = size.Height; ``` The subsequent validation logic (checking if width/height is 0 and falling back to constraints if valid) remains the same, ensuring backward compatibility while preventing infinite values from being used in calculations. ### What NOT to Do (for future agents) - ❌ **Don't use constraint values directly without checking for infinity** - Constraints can be infinite in scrollable containers (ScrollView, ListView). Always validate constraints before using them, or prefer using measured size from the native control. - ❌ **Don't assume constraints are always finite in GetDesiredSize** - Layout containers frequently pass infinite constraints during measurement to determine intrinsic size. ### Regressed PR - #26629 ### Issues Fixed Fixes #26795 ### Platforms Tested - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Screenshot | Before Issue Fix | After Issue Fix | |----------|----------| | <video src="https://github.com/user-attachments/assets/40f039b4-dc76-421f-9161-f4f98e23f621"> | <video src="https://github.com/user-attachments/assets/632c0cf2-243d-489e-8bd2-baa0da7e05d5"> | </details> <details>

> [!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 a custom flyout icon, irrespective of the actual png image color, the icon is always black. ### Root Cause - The issue on iOS stems from a platform change introduced in iOS 26. In earlier versions of iOS, the navigation bar and its toolbar items followed a predictable tint inheritance model. MAUI sets the navigation bar’s tint color through the ShellNavBarAppearanceTracker.SetAppearance() method, and UIBarButtonItem automatically inherited this tint. Because the flyout icon uses template rendering mode, it correctly adopted the color defined by Shell.ForegroundColor. - However, in iOS 26, Apple changed the tint inheritance behavior so that UIBarButtonItem no longer inherits the tint from UINavigationBar. - Even though MAUI still assigns a tint to the navigation bar, the flyout icon falls back to the system default blue instead of using the intended shell foreground color. ### Description of Change To fix this, the tint color is now explicitly assigned to the UIBarButtonItem when it is created in the ShellPageRendererTracker.UpdateLeftToolBarItems()method. By directly setting the tint on the button, the icon correctly reflects the foreground color on both older iOS versions and iOS 26. ### Validated the behaviour in the following platforms - [x] Android - [ ] Windows #26148 - [x] iOS - [x] Mac ### Issues Fixed: Fixes #32867 Fixes #33971 ### Screenshots | Before | After | |---------|--------| | <img src="https://github.com/user-attachments/assets/93179414-adc2-426a-ac04-2a2fa4e19d99"> | <img src="https://github.com/user-attachments/assets/52819946-8813-4769-be22-6c321be686a4"> |

…ing Index Value (#27246) ### Issue Details The ScrollTo method does not work correctly in a CollectionView when scrolling based on an index. This issue occurs only when the CollectionView includes a header. ### Root Cause The CollectionView considers the header as the zeroth index. Consequently, the scrolling does not navigate to the correct item index. ### Description of Change Modified the item position calculation to ensure proper scrolling behavior. Validated the behavior in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Issues Fixed Fixes #27117 ### Output ScreenShot | Before | After | |---------|--------| | <img width="389" alt="Screenshot 2025-01-21 at 6 33 20 PM" src="https://github.com/user-attachments/assets/8540c68d-7a65-4a29-8d99-626985312d33" /> | <img width="382" alt="Screenshot 2025-01-21 at 6 40 51 PM" src="https://github.com/user-attachments/assets/95aa220e-a008-4065-9ed4-0f19129831e1" /> | --------- Co-authored-by: Jakub Florkowski <kubaflo123@gmail.com>

…ent (#29228) ### Root Cause of the issue - When a background color is applied to an image, the image is `wrapped` inside a container view(`WrapperView`). However, when scaling is applied to the image, the container view (WrapperView) does not account for the `scaling`, resulting in incorrect rendering. ### Description of Change - Apply the scaling to the `container view` itself when a background color is present, ensuring proper rendering and consistent behavior. ### Issues Fixed Fixes #7432 ### Tested the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Screenshot | Before Issue Fix | After Issue Fix | |----------|----------| | <img src="https://github.com/user-attachments/assets/c01b5266-e982-4b86-a2b1-20f12f58dd95"> | <img src="https://github.com/user-attachments/assets/713f0699-b069-4317-bb5c-dc98c828d4ec"> |

…onView with image CarouselView (#31722)  > [!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 User used a CollectionView with a CarouselView containing images from randomly generated images. While scrolling, blank images may appear while loading. When an item is null or empty, the CarouselView.Position becomes -1. On Android, this causes an exception. ### Description of Change  Added a return check when Position == -1 to avoid the exception. This ensures no crash on Android ### Issues Fixed  Fixes #31680  **Tested the behavior in the following platforms.** - [x] Android - [x] Windows - [x] iOS - [x] Mac | Before | After | |---------|--------| | **Android**<br> <video src="https://github.com/user-attachments/assets/95faa64c-cb57-4664-af50-8bf3d0e649f4" width="300" height="600"> | **Android**<br> <video src="https://github.com/user-attachments/assets/7a34fc81-6e43-4f2f-99e5-4940c7d11225" width="300" height="600"> | --------- Co-authored-by: Matthew Leibowitz <mattleibow@live.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…msSource While Scrolled (#26782) ### Issue Details When modifying the CollectionView.ItemsSource while scrolled down in the list on Android, the ItemsViewScrolledEventArgs.VerticalOffset is not updated correctly. The offset "0" should always represent the start of the collection, but instead, it changes inconsistently when items are added or removed. This issue appears when the collection is scrolled beyond the position of the added or deleted items. ### Root Cause The offsets (VerticalOffset and HorizontalOffset) were being calculated incrementally and did not reset properly when the ItemsSource changed, leading to incorrect offset values. ### Description of Change The change resets the VerticalOffset and HorizontalOffset to 0 when the ItemsSource is updated. This ensures correct offset values after adding or removing items, fixing the issue of incorrect offsets while scrolling. ### Issues Fixed  Fixes #21708  ### Validated the behaviour in the following platforms - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Output Screenshot | Before | After | |---------|--------| | <video src="https://github.com/user-attachments/assets/c38a285b-f916-4dde-9811-9c19c0e96f96" width="320" height="240" controls></video> | <video src="https://github.com/user-attachments/assets/8e054051-566c-4857-9380-fd15eccc7849" width="320" height="240" controls></video> |

> [!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 pull request resolves the test failure that occurred in this PR #33622 when enabling the UI test for iOS 26. This PR updates the handling of virtual keyboard dismissal and improves back arrow query logic for iOS in the Appium test utilities. The main changes enhance reliability when interacting with the iOS keyboard and add support for identifying the correct back button based on the iOS version. * Enables lane for testing uitests on iOS26 **iOS Keyboard Interaction Improvements:** * In iOS 26, HideKeyboard does not tap the return key because the return key string changed from “return” to an arrow button in iOS 26, so the keyboard does not close, which causes the test to fail. The method for dismissing the keyboard now explicitly locates and clicks the “Return” button within the keyboard UI instead of using the generic HideKeyboard command, which increases reliability. **iOS Back Arrow Query Logic:** * In iOS 26, the back arrow ID changed to BackButton, so Appium does not find the back arrow. For iOS, the logic now checks the platform version iOS 26 or lower. For iOS 26 and higer versions it uses the accessibility ID "BackButton" and for lower versions it uses accessibility ID "Back". This ensures compatibility with UI changes across iOS versions. --------- Co-authored-by: Shane Neuville <shneuvil@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comparing changes

Open a pull request

Uh oh!

Commits on Feb 21, 2026

This comparison is taking too long to generate.

Uh oh!