[Testing] Refactoring Feature Matrix UITest Cases for Entry Control - #34632
Closed
LogishaSelvarajSF4525 wants to merge 236 commits into
Closed
[Testing] Refactoring Feature Matrix UITest Cases for Entry Control#34632LogishaSelvarajSF4525 wants to merge 236 commits into
LogishaSelvarajSF4525 wants to merge 236 commits into
Conversation
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 34632Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 34632" |
Contributor
|
Hey there @@LogishaSelvarajSF4525! 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
NafeelaNazhir
added
area-testing
Contributor
|
/azp run maui-pr-uitests |
sheiksyedm
marked this pull request as ready for review
March 26, 2026 10:54
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR refactors the Entry Feature Matrix page and options UI to be more testable and easier to reset between scenarios, while updating platform snapshot baselines to reflect the UI/test behavior changes.
Changes:
- Add new bindable properties to the Entry feature matrix (WidthRequest, BackgroundColor, Opacity) and centralize state reset via
EntryViewModel.Reset(). - Simplify the options UI event handling (e.g., using
AutomationIdto select colors; new handlers for width/opacity/height inputs; updated font attributes handling). - Update WinUI/macOS/iOS snapshot images to match the updated UI/test baselines.
Reviewed changes
Copilot reviewed 6 out of 148 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| src/Controls/tests/TestCases.HostApp/FeatureMatrix/EntryControl/EntryViewModel.cs | Adds new properties (BackgroundColor/Opacity/WidthRequest) and a Reset() method to restore defaults for test runs. |
| src/Controls/tests/TestCases.HostApp/FeatureMatrix/EntryControl/EntryOptionsPage.xaml.cs | Refactors option handlers (color selection by AutomationId, numeric input handlers, font-attributes checkbox aggregation). |
| src/Controls/tests/TestCases.HostApp/FeatureMatrix/EntryControl/EntryControlPage.xaml.cs | Uses _viewModel.Reset() instead of re-instantiating the view model when navigating to options. |
| src/Controls/tests/TestCases.HostApp/FeatureMatrix/EntryControl/EntryControlPage.xaml | Binds new properties to the Entry, updates Options AutomationId, and wires CursorPositionEntry TextChanged for better interactivity. |
| src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyClearButtonVisiblityWhenTextAlignedVertically.png | Updated iOS snapshot baseline. |
| src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyClearButtonVisiblityWhenTextAlignedHorizontally.png | Updated iOS snapshot baseline. |
| src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/ClearButtonVisiblityButton_TextPresent.png | Updated iOS snapshot baseline. |
| src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/ClearButtonVisiblityButton_TextEmpty.png | Updated iOS snapshot baseline. |
| src/Controls/tests/TestCases.iOS.Tests/snapshots/ios-26/VerifyTextWhenAlingnedVertically.png | Updated iOS 26 snapshot baseline. |
| src/Controls/tests/TestCases.iOS.Tests/snapshots/ios-26/VerifyTextWhenAlingnedHorizontally.png | Updated iOS 26 snapshot baseline. |
| src/Controls/tests/TestCases.iOS.Tests/snapshots/ios-26/VerifyClearVisiblityButtonWhenTextColorChanged.png | Updated iOS 26 snapshot baseline. |
| src/Controls/tests/TestCases.iOS.Tests/snapshots/ios-26/VerifyClearButtonVisiblityWhenTextAlignedVertically.png | Updated iOS 26 snapshot baseline. |
| src/Controls/tests/TestCases.iOS.Tests/snapshots/ios-26/VerifyClearButtonVisiblityWhenTextAlignedHorizontally.png | Updated iOS 26 snapshot baseline. |
| src/Controls/tests/TestCases.iOS.Tests/snapshots/ios-26/ClearButtonVisiblityButton_TextPresent.png | Updated iOS 26 snapshot baseline. |
| src/Controls/tests/TestCases.iOS.Tests/snapshots/ios-26/ClearButtonVisiblityButton_TextEmpty.png | Updated iOS 26 snapshot baseline. |
| src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/VerifyTextWhenAlignedVertically.png | Updated WinUI snapshot baseline. |
| src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/VerifyTextWhenAlignedHorizontally.png | Updated WinUI snapshot baseline. |
| src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/VerifyIsPasswordWhenMaxLengthSetValue.png | Updated WinUI snapshot baseline. |
| src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/VerifyClearVisibilityButtonWhenTextColorChanged.png | Updated WinUI snapshot baseline. |
| src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/VerifyClearButtonVisibilityWhenTextAlignedVertically.png | Updated WinUI snapshot baseline. |
| src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/VerifyClearButtonVisibilityWhenTextAlignedHorizontally.png | Updated WinUI snapshot baseline. |
| src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/VerifyClearButtonVisibilityWhenIsPasswordTrueOrFalse.png | Updated WinUI snapshot baseline. |
| src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/ClearButtonVisibilityButton_TextPresent.png | Updated WinUI snapshot baseline. |
| src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/ClearButtonVisibilityButton_TextEmpty.png | Updated WinUI snapshot baseline. |
| src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/VerifyTextWhenAlignedVertically.png | Updated macOS snapshot baseline. |
| src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/VerifyTextWhenAlignedHorizontally.png | Updated macOS snapshot baseline. |
| src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/VerifyIsPasswordWhenMaxLengthSetValue.png | Updated macOS snapshot baseline. |
| src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/VerifyClearVisibilityButtonWhenTextColorChanged.png | Updated macOS snapshot baseline. |
| src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/VerifyClearButtonVisibilityWhenTextAlignedHorizontally.png | Updated macOS snapshot baseline. |
| src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/VerifyClearButtonVisibilityWhenIsPasswordTrueOrFalse.png | Updated macOS snapshot baseline. |
| src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/ClearButtonVisibilityButton_TextPresent.png | Updated macOS snapshot baseline. |
| src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/ClearButtonVisibilityButton_TextEmpty.png | Updated macOS snapshot baseline. |
MauiBot
added
s/agent-review-incomplete
s/agent-reviewed
Collaborator
|
/azp run maui-pr-uitests |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This was referenced Mar 28, 2026
This was referenced Apr 6, 2026
…tackLayout at runtime (dotnet#32267) <!-- 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 removing children from a ScrollView that contains a StackLayout, the ScrollView does not resize correctly and leaves blank space at the bottom. ### Root Cause In MauiScrollView.LayoutSubviews(), when removing children, during the first layout pass the current ScrollView size is returned from CrossPlatformMeasure. Because of this, InvalidateAncestorMeasures() is not triggered, and the layout does not update as expected. ### Description of Change <!-- Enter description of the fix in this section --> Modified the logic to ensure that whenever a frame change occurs, InvalidateAncestorMeasures() is invoked. This ensures that the layout updates correctly, resolving the resizing issue when children are removed from the ScrollView. ### 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#32221 Fixes dotnet#20586 Fixes dotnet#34536 <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. --> **Tested the behavior in the following platforms.** - [x] Android - [x] Windows - [x] iOS - [x] Mac | Before | After | |---------|--------| | **iOS**<br> <video src="https://github.com/user-attachments/assets/bfb8ed3f-a2b3-4684-8e73-e036f29f5c2d" width="300" height="600"> | **iOS**<br> <video src="https://github.com/user-attachments/assets/aaf367da-da62-4b27-b103-06dc48c9e187" width="300" height="600"> |
<!-- 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 the FontSize is set on a control, font scaling is correctly applied at app startup based on the system's font scaling setting. However, if the user changes the system font size while the app is running, the font does not dynamically update — the app must be killed and restarted for the new font size to take effect. ### Root Cause of the issue - `FontManager.iOS.cs` caches scaled `UIFont` instances in a `ConcurrentDictionary<Font, UIFont>`. The cache key is the `Font` struct (family, size, weight, etc.).Once cached, the same `UIFont` is returned on every subsequent request — even after the user changes the Dynamic Type size — because the `Font` struct key hasn't changed. ### Description of Change Dynamic Type font scaling improvements: * [`src/Core/src/Fonts/FontManager.iOS.cs`](diffhunk://#diff-a03afeb4430f582df766a7060aaba9ba77d714108485b81d726dec246706a65aR43-R47): Added an observer for `ContentSizeCategoryChanged` notifications to clear the font cache in `_fonts`, ensuring new fonts are generated with the correct scaling when the user's preferred content size category changes. * [`src/Core/src/Platform/iOS/PageViewController.cs`](diffhunk://#diff-2f30bb28cbc0173a8383e90a546fc0e8f3bc221659b547a4f57591ca5b6a0b83R78-R87): In `TraitCollectionDidChange`, added logic to detect changes in the preferred content size category and call `InvalidateFontsOnContentSizeChanged` to update fonts across all text elements in the current view. * [`src/Core/src/Platform/iOS/PageViewController.cs`](diffhunk://#diff-2f30bb28cbc0173a8383e90a546fc0e8f3bc221659b547a4f57591ca5b6a0b83R100-R124): Introduced the `InvalidateFontsOnContentSizeChanged` method, which recursively updates font values and invalidates measurements for all text elements with auto-scaling enabled, ensuring immediate UI updates. ### 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#34307 ### Tested the behaviour in the following platforms - [x] - Windows - [x] - Android - [x] - iOS - [ ] - Mac | Before | After | |----------|----------| | <video src="https://github.com/user-attachments/assets/e5908baa-dbc8-4b57-9f8b-15b2dbf7dcda"> | <video src="https://github.com/user-attachments/assets/2149acec-9961-45f6-81b0-d13771859304"> | <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. --> --------- Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…otnet#31913) <!-- 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. !!!!!!! --> On Windows, the StorageFile.ContentType API often returns a generic or incorrect MIME type (e.g., .webp → application/octet-stream), causing FilePicker to report wrong or empty ContentType values. <!-- Enter description of the fix in this section --> Fixed by adding an extension-to-MIME mapping dictionary in FileSystem.uwp.cs that includes .webp and other formats. The solution uses fallback logic - it preserves Windows' native ContentType when correct, but automatically uses our mapping when Windows returns the generic "application/octet-stream" or empty values. <!-- 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#31808 <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. --> **Tested the behavior in the following platforms.** - [x] Windows - [x] Mac | Before | After | |---------|--------| | **Windows**<br> <video src="https://github.com/user-attachments/assets/767358b1-4129-4be8-9817-8dcc83868e0b" width="600" height="300"> | **Windows**<br> <video src="https://github.com/user-attachments/assets/71d47ced-2c26-4fdd-b6e1-d2e2c24f3157" width="600" height="300"> | --------- Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
… row and column (dotnet#34598) <!-- 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 iOS,Mac and 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. On iOS and MacCatalyst, the active Items2 compositional layout path handled spacing in a way that visually created gaps but did not cause the first column and first row to update consistently with the rest of the grid. ### Description of Change: - On iOS/MacCatalyst, the fix in LayoutFactory2.cs keeps the existing compositional grid item sizing (FractionalWidth(1f / span) for vertical grids and FractionalHeight(1f / span) for horizontal grids), but changes how spacing is applied. Instead of relying on group.InterItemSpacing, the fix computes half of the requested horizontal and vertical spacing and applies that half-spacing through item.ContentInsets so each item contributes to the gap. It then sets group.InterItemSpacing to 0, keeps section.InterGroupSpacing for spacing between rows or columns, and adds matching half-spacing to section.ContentInsets. This makes the first row/column participate when spacing changes, which fixes the issue where only later rows or columns visually updated. **Tested the behavior in the following platforms: ** - [ ] Android - [ ] Windows - [x] iOS - [x] 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"> |
…ot update dynamically at runtime (dotnet#35893) <!-- Please keep the note below for people who 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 whether this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> This pull request improves the runtime update behavior of `SearchHandler` icons (`QueryIcon`, `ClearIcon`, and `ClearPlaceholderIcon`) across Android, iOS, and Windows platforms. It ensures that changes to these icon properties are reflected visually without requiring a restart or navigation. The update also adds new test cases and a sample page to verify and demonstrate this functionality. ### Description of Change **Platform-specific icon update support:** - **Android:** - Added logic in `ShellSearchView.cs` to listen for changes to `QueryIcon`, `ClearIcon`, and `ClearPlaceholderIcon` properties and update the corresponding buttons immediately. Refactored image loading into a reusable `ApplyImageSource` method. [[1]](diffhunk://#diff-cd10009f7e4bc472ed235e594c3d3b7a87df79b413c1a0acf6edee9e73840176R243-R284) [[2]](diffhunk://#diff-cd10009f7e4bc472ed235e594c3d3b7a87df79b413c1a0acf6edee9e73840176L319-R361) - **iOS:** - Enhanced `ShellPageRendererTracker.cs` to update search bar icons at runtime for `QueryIcon`, `ClearIcon`, and `ClearPlaceholderIcon`. Added a workaround to force-refresh the clear button image, addressing iOS caching behavior. [[1]](diffhunk://#diff-7649316957d61ad7ad533c7a27d303e022ef35c1fe79b8568ca34c85ce81a719R920-R931) [[2]](diffhunk://#diff-7649316957d61ad7ad533c7a27d303e022ef35c1fe79b8568ca34c85ce81a719R1163-R1215) - **Windows:** - Updated `ShellItemHandler.Windows.cs` to support dynamic updates for `QueryIcon`. Added comments and tracking for unsupported icons (`ClearIcon`, `ClearPlaceholderIcon`). **Testing and sample coverage:** - **New sample page:** - Introduced `Issue35736` sample page to manually test toggling of all three icon properties and resetting them to defaults at runtime. - **Automated UI tests:** - Added UITest cases for all icon properties to ensure they update visually at runtime and after reset, with platform-specific handling for unsupported features. <!-- 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#35736 ### Tested the behavior in the following platforms - [x] Windows - [x] Android - [x] iOS - [x] Mac | Before Issue Fix | After Issue Fix | |----------|----------| | <video src="https://github.com/user-attachments/assets/7a105556-4c64-4012-8668-a5829a3c3a13"> | <video src="https://github.com/user-attachments/assets/008e86ec-d97d-46fe-a6c0-04104f7a794e"> | | Before Issue Fix | After Issue Fix | |----------|----------| | <video src="https://github.com/user-attachments/assets/d010995c-b244-4a1a-bbca-b4b33f0f166a"> | <video src="https://github.com/user-attachments/assets/9acb925f-e4b9-46ff-903d-f34432f22367"> | <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. --> ---------
…board dismiss (dotnet#35960) <!-- 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 iOS, when Shell.BackgroundColor="Transparent", navigating to a secondary page correctly shows the nav bar as transparent. After tapping an Entry and dismissing the keyboard, the navigation bar incorrectly appears with a solid opaque background, hiding the page color beneath it. ### Root Cause PR dotnet#33958 added an OnKeyboardWillHide handler in ShellPageRendererTracker to fix issue dotnet#33547, which repositions the page frame from Y=0 to Y=navBarBottom whenever the keyboard closes. For transparent Shell, Y=0 is intentional (page content extends behind the bar), but the handler moved the frame unconditionally, pulling content out from under the transparent nav bar and making it appear opaque. ### Description of Change A guard was added inside OnKeyboardWillHide to skip the frame adjustment when the navigation bar is transparent, since the page content at Y=0 is intentional in that case. The guard checks navBar.Translucent, which MAUI already sets to true for transparent Shell making it a reliable signal. The original dotnet#33547 fix is fully preserved for opaque navigation bars Validated the behavior in the following platforms - [ ] Android - [ ] Windows - [x] iOS - [ ] Mac ### Issues Fixed Fixes dotnet#35902 ### Output ScreenShot |Before|After| |--|--| | <video src="https://github.com/user-attachments/assets/98d6eb82-3fc9-4328-b871-4a4762efcdb3" >| <video src="https://github.com/user-attachments/assets/cb958d3b-8551-4b9e-904d-395123d2d8bb">|
…33192) <!-- 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: Unable to scrolling vertically / horizontally when scrollview placed in Shell.FlyoutHeader in Android platform. The issue doesn't occur in iOS,Mac and windows platforms. ### Root Cause: The issue occurs because Android's DrawerLayout (which powers the Shell Flyout) uses touch event interception to handle the pan gesture that opens and closes the flyout menu. When a ScrollView is placed inside the Shell.FlyoutHeader, the DrawerLayout intercepts touch events before they can reach the ScrollView. This interception happens in the DrawerLayout.OnInterceptTouchEvent() method, which is designed to detect horizontal swipe gestures. However, when a user attempts to scroll vertically within the ScrollView, the DrawerLayout interprets any touch movement as a potential flyout gesture and intercepts the event, preventing the ScrollView from receiving it. As a result, the ScrollView never processes the scroll gesture, and instead, the touch movement is consumed by the DrawerLayout's flyout pan gesture handler. This creates a conflict where vertical scrolling becomes impossible because the parent container's gesture recognition takes priority over the child ScrollView's scroll handling. The user reported that attempting to scroll the content in the flyout header would close the flyout instead of scrolling, which confirms that the DrawerLayout is intercepting and handling the touch events rather than allowing them to reach the ScrollView. ### Description of Change: The fix implements the standard Android pattern for resolving nested scrolling conflicts by using the RequestDisallowInterceptTouchEvent() API. This method allows a child view to request that its parent not intercept touch events during active touch handling. The fix was applied to both MauiScrollView.OnTouchEvent() and MauiHorizontalScrollView.OnTouchEvent() methods in the src/Core/src/Platform/Android/MauiScrollView.cs file. When a touch begins (MotionEventActions.Down), the ScrollView calls Parent?.RequestDisallowInterceptTouchEvent(true), which tells the parent DrawerLayout to stop intercepting touch events for this gesture sequence. This allows the ScrollView to receive and process all subsequent touch events in the gesture, enabling normal scrolling behavior. When the touch ends (MotionEventActions.Up) or is cancelled (MotionEventActions.Cancel), the ScrollView calls Parent?.RequestDisallowInterceptTouchEvent(false) to restore the parent's ability to intercept touch events for future gestures. This ensures that after scrolling completes, the flyout's horizontal swipe-to-close gesture continues to work normally. **Tested the behavior in the following platforms.** - [x] Android - [x] Windows - [x] iOS - [x] Mac ### Reference: N/A ### Issues Fixed: Fixes dotnet#11764 ### Screenshots | Before | After | |---------|--------| | <Video width="380" height="1000" alt="image (6)" src="https://github.com/user-attachments/assets/3ea26fee-4aa5-43f8-be95-2ceac2ab231e" /> | <Video width="380" height="1000" alt="image (6)" src="https://github.com/user-attachments/assets/612a25c4-872f-42ca-a181-cd0e5d8358f7" /> |
…resources (dotnet#36097) <!-- Please keep the note below for people who 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 whether this change resolves your issue. Thank you!<!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Details Path.Data and Path.RenderTransform can cause memory leaks when they use shared long-lived resources (PathGeometry / ScaleTransform). The shared resource stays alive for app lifetime, and its event subscriptions can keep old Path controls alive after a page is popped. Because those Path controls stay alive, related page objects and binding context data may also be retained.This is reproducible across platforms. ### Description of Change <!-- Enter description of the fix in this section --> Added weak-event subscription handling so Path no longer holds strong references through shared geometry/transform change events. ### 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#35860 <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. --> **Tested the behavior in the following platforms.** - [x] Android - [x] Windows - [x] iOS - [x] Mac | Before | After | |---------|--------| | **iOS**<br> <video src="https://github.com/user-attachments/assets/5bbfab0e-1978-46f9-91e2-a93b5b037ced" width="300" height="600"> | **iOS**<br> <video src="https://github.com/user-attachments/assets/98c362a0-a10e-411b-91b6-d612105958a2" width="300" height="600"> |
…r handler restore when property changes (dotnet#36073) <!-- Please keep the note below for people who 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 whether this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> This pull request addresses a regression issue where `CollectionViewHandler2` could throw a `NullReferenceException` if a layout property changed after the handler was disconnected and then reconnected. The fix ensures the internal cache is properly reinitialized, and new tests are added to verify the handler's stability in these scenarios. ### Description of Change **Bug fix:** - Ensured `_layoutPropertyCache` is reinitialized when subscribing to a new items layout in `CollectionViewHandler2`, preventing `NullReferenceException` after handler disconnect/reconnect cycles. **Testing improvements:** - Added regression tests to confirm that changing properties on `GridItemsLayout` and `LinearItemsLayout` after a disconnect/restore cycle does not cause crashes in `CollectionViewHandler2`. These tests cover various property changes and validate the fix <!-- 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#36010 ### Tested the behavior in the following platforms - [ ] Windows - [ ] Android - [x] iOS - [x] Mac | Before Issue Fix | After Issue Fix | |----------|----------| | <img width="954" height="693" alt="BeforeFix36010" src="https://github.com/user-attachments/assets/fb32509b-ce7c-497c-9fa4-3170181e9475" /> | <img width="947" height="689" alt="AfterFix36010" src="https://github.com/user-attachments/assets/188f6e3b-6b72-4ead-9af0-342d5d8d7c20" /> | <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. -->
…s MSB4019) (dotnet#36089) <!-- 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 the **nightly official signed build** (`dotnet-maui`, definition 1095, dnceng/internal), which has failed **8 consecutive nights** on `refs/heads/inflight/current`. The Windows `Pack` job → step **"Build Workloads, Sign & Publish"** fails at restore/evaluation: ``` src\Workload\workloads.csproj(30,3): error MSB4019: The imported project "...\artifacts\packages\Release\Shipping\vs-workload.props" was not found. ``` ### Root cause The workload packs — `Microsoft.NET.Sdk.Maui.Manifest` and `Microsoft.Maui.Sdk` — both target **`netstandard2.0`** (via `src/Workload/Shared/Common.targets`) and both **explicitly** set `<IsPackable>true</IsPackable>` because they *are* the shipping workload packages. PR dotnet#32203 ("Don't pack .NET Standard") added a blanket rule to `Directory.Build.targets`: ```xml <IsPackable Condition="$(TargetFramework.Contains('netstandard'))">false</IsPackable> ``` `Directory.Build.targets` is auto-imported at the **end** of every project, so this assignment runs *after* the project body and **overrides** the explicit `<IsPackable>true</IsPackable>` on the workload packs. The net effect: the manifest project evaluates to `IsPackable=false`. The chain that breaks from there: 1. With `IsPackable=false`, NuGet's `Pack` target no-ops. 2. The official **"Pack, Sign"** step (`eng/pipelines/arcade/stage-pack.yml`) runs `-restore -pack -sign` **without `-build`**, so the `Build` target never runs for the manifest project. 3. `_GenerateVSWorkloadProps` (in `Microsoft.NET.Sdk.Maui.Manifest.csproj`) is hooked `AfterTargets="Build"`, so it never runs → `vs-workload.props` is never written to `$(ArtifactsShippingPackagesDir)`. 4. The next step (`-build … -projects src/Workload/workloads.csproj`) hits `workloads.csproj` line 30, whose `<Import Project="$(WorkloadMsiGenProps)" />` is unconditional and fails at evaluation → **MSB4019**. The blanket rule is also **over-broad**: it clobbers the explicit opt-in on *every* netstandard-only project, not just the workload packs (see **Scope** below). The workload/MSI leg simply failed loudest because its missing-file import is fatal at evaluation (MSB4019); the others would silently stop shipping. **Why `main` is green:** PR dotnet#32203 is on `inflight/current` only — it is *not* an ancestor of `main` or `net10.0` (verified with `git merge-base --is-ancestor`). `main` and `inflight/current` otherwise share identical `global.json` (dotnet `10.0.108`, arcade `25555.106`), identical `src/Workload`, and identical `Microsoft.Build.NoTargets 3.7.0`. The only relevant difference is the dotnet#32203 block, which is why this break is specific to `inflight/current`. ### Fix Guard the dotnet#32203 rule so it only applies when a project has **not** explicitly opted into packing: ```xml <IsPackable Condition="$(TargetFramework.Contains('netstandard')) and '$(IsPackable)' == ''">false</IsPackable> ``` - Projects that explicitly set `<IsPackable>true</IsPackable>` (the workload packs) are respected and pack again — restoring `vs-workload.props` generation. - Unmarked netstandard projects still default to not-packable, **preserving dotnet#32203's intent**. This restores the exact condition (`IsPackable=true` for the manifest project) that the passing `main` build exhibits, where `_GenerateVSWorkloadProps` runs and `vs-workload.props` is produced. ### Scope / blast radius Because dotnet#32203's blanket rule was over-broad, this guard restores packability for **6** netstandard-only projects that explicitly opt in — not just the 2 workload packs: | Project | TFM | |---|---| | `Microsoft.NET.Sdk.Maui.Manifest` | `netstandard2.0` | | `Microsoft.Maui.Sdk` | `netstandard2.0` | | `Resizetizer` | `netstandard2.0` | | `Controls.Build.Tasks` | `netstandard2.0` | | `Controls.SourceGen` | `netstandard2.0` | | `Graphics.Text.Markdig` | `netstandard2.0` | All 6 pack on `main` (which never had the dotnet#32203 rule), so this is a **`main`-parity restore**, not new shipping behavior. Multi-target libraries (e.g. `Core`, `Controls.Core`) are unaffected: `dotnet pack` evaluates `IsPackable` at the outer level where `TargetFramework=""`, so the netstandard rule never fires for them. ### How validated Root cause confirmed from the actual failing/passing build binlogs (not guesswork): | | failing `inflight/current` build `3006161` | passing `main` build `3006214` | |---|---|---| | `Microsoft.NET.Sdk.Maui.Manifest` `IsPackable` | **`false`** | **`true`** | | `_GenerateVSWorkloadProps` ran? | no (Build never ran) | yes → `vs-workload.props` produced | Verified locally on the `inflight/current` tree with `dotnet msbuild …Manifest.csproj -getProperty:IsPackable`: - **Before** fix: manifest `IsPackable=false` (reproduces the break). - **After** fix: manifest `IsPackable=true`, `Microsoft.Maui.Sdk` `IsPackable=true`. - `Microsoft.Maui.Core` (multi-target) at pack time is unchanged (`IsPackable=true`, `TargetFramework=""`; the netstandard rule only fires for single-TFM netstandard evaluations, so multi-target library packaging is unaffected). - A netstandard project with no explicit opt-in (`Controls.CustomAttributes`) still resolves `IsPackable=false` — dotnet#32203's intent preserved. The full signed Windows MSI leg only runs in the official pipeline; this change restores the property state that gates the entire pack → `vs-workload.props` → workloads handoff. **PR CI confirms the fix end-to-end:** on base `inflight/current` the `Pack Windows` leg fails at the root-cause spot; on this PR the same leg is green. The remaining red `maui-pr` legs are pre-existing on `inflight/current` (Windows Helix unit-test flakiness identical on base, and integration legs that were *skipped on base* because Pack was blocked and only run now that the fix unblocked Pack). ### Follow-up note When PR dotnet#32203's `Directory.Build.targets` change is forward-ported to `net10.0`/`main`, it must carry this `'$(IsPackable)' == ''` guard, otherwise the same break will reappear on those branches. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This pull request improves the integration test for the Aspire Service Defaults template by adding more thorough validation of the generated project. The changes focus on ensuring the template produces a buildable project and that the project file contains all required properties. Enhancements to integration test coverage: * Added a build verification step to ensure the generated project from the `maui-aspire-servicedefaults` template can be successfully built, catching issues early in the test process. * Added an assertion to verify that the generated project file includes the `<UseMauiCore>true</UseMauiCore>` property, in addition to the existing Aspire-specific properties check.
…nsions to IDrawable.Draw (dotnet#34564) <!-- 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 - In a simple layout where a parent ContentView sets fixed size (Height=50, Width=100) and hosts a custom GraphicsView with an IDrawable implementation, the Draw(ICanvas canvas, RectF dirtyRect) method receives fractional dimensions (e.g., 50.28 x 100.19) instead of the expected 50 x 100. - This leads to improper drawing, such as thinner lines, off-by-one strokes, and visible border breaks due to the sub-pixel canvas size. ### Root Cause - **Android**: PlatformGraphicsView passes raw fractional dp values as dirtyRect to IDrawable.Draw(). These fractions arise because Android layouts are calculated in whole pixels, and converting back to dp results in non-integer values (e.g., 263px ÷ 2.625 = 100.19 dp). - **Windows:** PlatformGraphicsView passes raw fractional DIP values as dirtyRect to IDrawable.Draw(). This occurs because WinUI aligns layout to whole physical pixels, and converting back to DIPs produces non-integer values (e.g., 63px ÷ 1.25 = 50.4 DIPs). ### Description of Change - **Android**: The logic in PlatformGraphicsView now precomputes logical (dp) dimensions by rounding to the nearest integer and adjusts scaling factors so that the logical dimensions, when scaled, exactly match the pixel allocation. This prevents fractional dp values and sub-pixel gaps. (src/Graphics/src/Graphics/Platforms/Android/PlatformGraphicsView.cs). - **Windows**: The OnDraw method in PlatformGraphicsView now rounds the actual size to integer logical dimensions, adjusts the scale accordingly, and applies this scale via the platform canvas. This ensures the drawable area always matches the view's pixel size exactly, with no fractional or sub-pixel rendering. (src/Graphics/src/Graphics/Platforms/Windows/PlatformGraphicsView.cs). ### Issues Fixed Fixes dotnet#33110 ### Validated the behaviour in the following platforms - [x] Windows - [x] Android - [ ] iOS - [ ] Mac ### Output | Platform | Before | After | |----------|----------|----------| | Android | <video src="https://github.com/user-attachments/assets/53231732-37e4-4452-b6eb-90fbb15cc6fe"> | <video src="https://github.com/user-attachments/assets/de782018-5b51-473c-9f3b-805f319cf4cf"> | | Windows | <video src="https://github.com/user-attachments/assets/19051640-33b0-436f-82bf-f770ff604310"> | <video src="https://github.com/user-attachments/assets/df1f97b9-6c32-413c-bc81-4ad917ef8d9d"> | --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…rm (dotnet#36079) <!-- 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 the cursor is at a mid-text position in an Entry with TextTransform set, typing a character resets the cursor to the end of the text instead of advancing it by one position. ### Root Cause - On iOS/macCatalyst, each access to UITextField.AttributedText returns a new C# wrapper object around the same native ObjC instance, so the != guard in UpdateMaxLength was always true, causing an unconditional AttributedText assignment on every keystroke — which UIKit uses as a signal to reset the cursor to the end of the text. ### Description of Change - Cache textField.AttributedText in a local variable and use ReferenceEquals as the guard, so the assignment is skipped when TrimToMaxLength returns the same instance (i.e., no trimming was needed), preserving the cursor position. ### Issues Fixed Fixes dotnet#36018 ### Validated the behaviour in the following platforms - [ ] Windows - [ ] Android - [x] iOS - [x] Mac ### Output | Before | After | |----------|----------| | <video src="https://github.com/user-attachments/assets/fdeccb91-df21-4fd9-a0c3-2d331f00e056"> | <video src="https://github.com/user-attachments/assets/f927a51d-bfc3-4f48-bfab-45ab9aae93d8">
kubaflo
force-pushed
the
inflight/current
branch
from
June 25, 2026 20:02
81295ab to
34a8f02
Compare
…net#34791) <!-- 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! ## Summary Updates Windows App SDK and related Windows dependencies to the latest versions whose **full restore closure is available on the `dotnet-public` ADO feed** — keeping this a clean, single-file change. ### Package Updates | Package | Old Version | New Version | |---------|------------|-------------| | **Microsoft.WindowsAppSDK** | 1.8.251106002 | **1.8.260529003** | | **Microsoft.Windows.SDK.BuildTools** | 10.0.26100.4654 | **10.0.26100.8249** | | **Microsoft.Graphics.Win2D** | 1.3.2 | **1.4.0** | `Microsoft.Web.WebView2` stays at `1.0.3179.45` — the version WindowsAppSDK `1.8.x` pins via its `.WinUI` sub-package. ### Why 1.8.x and not 2.0.1 WindowsAppSDK **2.0** externalized its ML component into a separate `Microsoft.Windows.AI.MachineLearning` package (pulled transitively via `Microsoft.WindowsAppSDK.ML` → `[2.0.300, 3.0.0)`). That package is published to **nuget.org but is not mirrored to the dnceng `dotnet-public` feed**, so targeting `2.0.1` required two extra workarounds: - a `nuget.org` package source in `NuGet.config` (otherwise restore fails with `NU1101`), and - an `NU1603` suppression in `Directory.Build.props`. The latest **1.8.x** servicing release (`1.8.260529003`, ~7 months newer than the previous `1.8.251106002`) keeps a **self-contained** `.ML` sub-package — it depends on `System.Numerics.Tensors`, **not** `Microsoft.Windows.AI.MachineLearning` — and **every package in its closure is already on `dotnet-public`** (verified package-by-package). Both workarounds have been removed, so this is now a clean **`eng/Versions.props`-only** change. > Adopting WindowsAppSDK **2.0** later will require `Microsoft.Windows.AI.MachineLearning` (≥ `2.0.300`) to be mirrored into the dnceng `dotnet-public` feed first; until then, 2.0 can't be restored without a `nuget.org` source. ### Verification Every package in the `1.8.260529003` restore closure was confirmed present on `dotnet-public`. The actual Windows restore/build is validated by CI on this PR (the host used to prepare it is macOS). --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: kubaflo <kubaflo@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
…et#30378) <!-- 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 in mac when the app enters in full screen mode, titlebar content is not aligned to the left. ### Description of Change <!-- Enter description of the fix in this section --> Added logic to adjust the TitleBar content margin based on full-screen state (Mac Catalyst 16+). When in full-screen, left margin is removed; otherwise, a margin of 80 is applied to align with traffic light spacing. ### 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#30248 <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. --> **Tested the behavior in the following platforms.** - [ ] Android - [ ] Windows - [ ] iOS - [x] Mac | Before | After | |---------|--------| | **Mac**<br> <video src="https://github.com/user-attachments/assets/1224b070-4913-46ce-929d-bfd97f20ad47" width="600" height="300"> | **Mac**<br> <video src="https://github.com/user-attachments/assets/dd7de8c9-667a-486f-86c9-fcd9e450150b" width="600" height="300"> |
# Conflicts: # src/Controls/tests/TestCases.HostApp/FeatureMatrix/EntryControl/EntryControlPage.xaml.cs # src/Controls/tests/TestCases.HostApp/FeatureMatrix/EntryControl/EntryOptionsPage.xaml # src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/VerifyHorizontalTextAlignmentWhenVerticalTextAlignmentSet.png # src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/VerifyIsPasswordWhenMaxLenghtSetValue.png # src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/VerifyPlaceholderWithFontFamily.png # src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/VerifyPlaceholderWithFontSize.png # src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/VerifyTextWhenAlingnedHorizontally.png # src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/VerifyTextWhenAlingnedVertically.png # src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/VerifyTextWhenFontAttributesSet.png # src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/VerifyTextWhenFontFamilySetValue.png # src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/VerifyTextWhenFontSizeSetCorrectly.png # src/Controls/tests/TestCases.Shared.Tests/Tests/FeatureMatrix/EntryFeatureTests.cs # src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/VerifyHorizontalTextAlignmentWhenVerticalTextAlignmentSet.png # src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/VerifyIsPasswordBasedOnVerticalTextAlignment.png # src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/VerifyTextWhenFontAttributesSet.png # src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/ClearButtonVisiblityButton_TextEmpty.png # src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/PlaceholderWithClearButtonVisible.png # src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyHorizontalTextAlignmentWhenVerticalTextAlignmentSet.png # src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyPlaceholderWhenFlowDirectionSet.png # src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyPlaceholderWithCharacterSpacing.png # src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyPlaceholderWithFontAttributes.png # src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyPlaceholderWithFontFamily.png # src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyPlaceholderWithFontSize.png # src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyPlaceholderWithHorizontalAlignment.png # src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyTextWhenClearButtonVisibleSetNever.png # src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyTextWhenFontAttributesSet.png # src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyTextWhenFontFamilySetValue.png # src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyTextWhenFontSizeSetCorrectly.png # src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyTextWhenKeyboardTypeSet.png # src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyTextWhenReturnTypeSet.png
Collaborator
Conflicts resolved (merge
|
This comment has been minimized.
This comment has been minimized.
github-actions
Bot
added
the
s/agent-review-in-progress
MauiBot
removed
the
s/agent-review-in-progress
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
This comment has been minimized.
This comment has been minimized.
Contributor
Tests Failure Analysis
Test Failure Review: Needs human investigation - click to expandOverall verdict: Needs human investigation The base branch ( Coverage: 49 checks · 6 passing · 43 failing · 0 pending · 0 inaccessible · 1 unmapped · 53 unexplained build legs · 0 unaccounted failing checks · 0 aborted failing checks · 0 canceled-build checks · 2 device-test unverified · 10 unattributed · 0 regressed-vs-base. Deterministic ceiling: Needs human investigation — 1 failing check(s) have no inspectable AzDO build evidence (Build Analysis); 53 failed build leg(s) produced no extractable failure; 10 failure(s) could not be attributed deterministically; 2 device-test check(s) read GREEN but Failed==0 not positively confirmed.
Recommended actionA human reviewer should confirm whether the Windows PowerShell device-test build errors and the remaining indeterminate failures are pre-existing on the base branch; the base branch is consistently red and this is a test-only PR, strongly suggesting all failures are unrelated to the PR changes. Evidence details
|
kubaflo
requested changes
Jul 1, 2026
kubaflo
left a comment
kubaflo
left a comment
Collaborator
There was a problem hiding this comment.
Could you please check test failures?
Collaborator
|
Could you please create a new pr with related changes? |
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.
Note
Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!
This pull request updates the
EntryControlPageand its code-behind to improve testability and maintainability of the Entry control's feature matrix. The main changes include adding new bindable properties, improving event handling, and simplifying the options navigation logic.Enhancements to Entry control testability and UI:
WidthRequest,BackgroundColor, andOpacityto the Entry control inEntryControlPage.xamlto allow more comprehensive property testing.AutomationIdof the options button from"OptionsButton"to"Options"for consistency with test automation.TextChangedevent handler (CursorPositionButton_Clicked) to theCursorPositionEntrycontrol, enabling dynamic updates to cursor position via UI interaction.Code simplification and maintainability:
NavigateToOptionsPage_Clickedwith a call to the new_viewModel.Reset()method, making the reset logic more maintainable and centralized.Issue Identified: