Summary:
Using an external keyboard, the key command ↓ (down arrow) does not work correctly in certain situations, jumps to unexpected locations.
Steps to Reproduce:
Run the attached sample project on an iPad Simulator
Tap into the UITextView on screen
Using a long-press, place insertion point at the end of any wrapped line, e.g. after "ad" (this is important)
Ensure the External keyboard is connected
Press ↓ (down arrow)
Expected Results:
Tapping ↓ (down arrow) should move the insertion point down to a character below the insertion point.
Actual Results:
Tapping ↓ (down arrow) moves the insertion point to the beginning of the second-next line below!
Version:
iOS 9.3.1
Notes:
It seems as if the UITextInputTokenizer is not correctly respecting the selection affinity of the cursor placed in this way. The insertion point at the end of a wrapped line is ambiguous, since the respective character index also exists on the beginning of the next line. It seems the position is computed from that other position instead, which is incorrect.
Also:
Using ↑ (up arrow) in the same situation is similarly broken and places the cursor at the beginning of the current line, suggesting the computation is broken in the just mentioned way
The same happens when placing the cursor at the end of the line using ⌘→ (command-right), but this requires testing on a device
Configuration:
Any iOS device
Attachments:
'textedit v2.zip' was successfully uploaded. http://cl.ly/fk4d
Description
Summary: Using an external keyboard, the key command ↓ (down arrow) does not work correctly in certain situations, jumps to unexpected locations.
Steps to Reproduce:
Expected Results: Tapping ↓ (down arrow) should move the insertion point down to a character below the insertion point.
Actual Results: Tapping ↓ (down arrow) moves the insertion point to the beginning of the second-next line below!
Version: iOS 9.3.1
Notes: It seems as if the UITextInputTokenizer is not correctly respecting the selection affinity of the cursor placed in this way. The insertion point at the end of a wrapped line is ambiguous, since the respective character index also exists on the beginning of the next line. It seems the position is computed from that other position instead, which is incorrect.
Also:
Configuration: Any iOS device
Attachments: 'textedit v2.zip' was successfully uploaded. http://cl.ly/fk4d
Product Version: 9.3.1 Created: 2016-04-20T07:52:23.010810 Originated: 2020-04-16T00:00:00 Open Radar Link: http://www.openradar.me/25824543