[iOS] Fix for CursorPosition Property Not Applied Correctly to Entry Control #27220
Conversation
|
Hey there @praveenkumarkarunanithi! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed. |
|
/azp run |
jsuarezruiz
added
platform/iOS 🍎
area-controls-entry
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
karthikraja-arumugam
added
the
partner/syncfusion
praveenkumarkarunanithi
requested review from
StephaneDelcroix and
tj-devel709
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
|
||
| [Test] | ||
| [Category(UITestCategories.Entry)] | ||
| public void EntryShouldApplyCursorPositionCorrectly() |
There was a problem hiding this comment.
The build is failing because the cursor is blinking, not guaranteed will appear in the snapshot: EntryShouldApplyCursorPositionCorrectly
After merge #27277 just update the test to remove the cursor from the snapshots.
There was a problem hiding this comment.
@jsuarezruiz , Thanks for the feedback. The UI test is crucial for verifying that the cursor position is correctly applied to the Entry control, which is central to the fix. Removing the cursor from the snapshot could prevent us from validating this functionality accurately. How can we handle this?
|
/rebase |
|
/azp run |
github-actions
bot
force-pushed
the
19109-fix
branch
from
096918a to
536edb2
Compare
|
Azure Pipelines successfully started running 3 pipeline(s). |
Root Cause
The native iOS UITextField control does not directly expose a cursor position property. Instead, it uses SelectedTextRange to manage the cursor's position and selection. The issue arose because, during the OnEditingBegan event (which is triggered when the entry control is focused), the UpdateSelectionLength method was called. However, within UpdateSelectionLength, there is a condition that checks whether the difference between selectedTextRange.Start and selectedTextRange.End equals entry.SelectionLength. If this condition is not met, the method does not update the SelectedTextRange (i.e., the cursor position).
Description of Change
The solution was to conditionally call UpdateCursorPosition or UpdateSelectionLength based on the SelectionLength. If SelectionLength is greater than zero, UpdateSelectionLength is called, otherwise, UpdateCursorPosition is called. This ensures that when focusing the entry control, the cursor position and selection are both applied correctly.
Issues Fixed
Fixes #19109
Tested the behaviour in the following platforms
Screenshots