-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix visibility of selection handles in iOS when text is RTL or BiDi #1331
Fix visibility of selection handles in iOS when text is RTL or BiDi #1331
Conversation
...kitMain/kotlin/androidx/compose/foundation/text/selection/TextFieldSelectionManager.uikit.kt
Outdated
Show resolved
Hide resolved
internal actual fun TextFieldSelectionManager.isSelectionHandleInVisibleBound( | ||
isStartHandle: Boolean | ||
): Boolean { | ||
fun getSelectionHandleVisibilityPointPosition(isStartHandle: Boolean): Offset { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, can we have unit test for this logic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
During the second look, it seems it would be much easier to redefine contains check (which is supposed to be done based on description) instead of copy-pasting common code with a lot (6!) of conditions inside selection handle position calculation.
val visibleBounds = state?.layoutCoordinates?.visibleBounds() | ||
val handlePosition = getSelectionHandleVisibilityPointPosition(isStartHandle) | ||
|
||
return visibleBounds?.containsInclusive(handlePosition) ?: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems alternative of containsInclusive
with HeightToleranceFactor
should be defined instead of reinventing getHandlePosition
with their corner cases and transformations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rewrote it like this because I wanted to make proper check for coordinates of left and right selection handles (line 171), but it seems like it's not worth it.
Figured out how to arrange that properly, I'll rewrite soon. It won't be so simple as you suggested because I still need height for this solution, but it still be simpler than this.
9d80da9
to
fd18d36
Compare
50.0f, | ||
Rect(Offset(0f, 0f), Offset(744.0f, 50.0f)) | ||
) | ||
assert(isStartVisible && isEndVisible) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- It's better to use
assertTrue
orassertFalse
to verify visible and invisible results. - please use one assert for every condition, like:
assertTrue(isStartVisible)
assertFalse(isEndVisible)
acd092d
to
45c2185
Compare
…, added test screen in Components/TextField with RTL and BiDi examples
…nto separate method, added test cases for that method
45c2185
to
4f3ac09
Compare
Adjusted check of visibility of selection handles in iOS - they won't be shown when they are visible less than 80% of their size.
This change is required for making selection handles visible when a single line textfield contains LTR + RTL text, before this fix selection handles weren't visible.
In addition, during scrolling the long textfield, selection handles will be hiding more smoothly than before.
Fixes: https://youtrack.jetbrains.com/issue/COMPOSE-1359/iOS-Selection-Handles-work-weirdly-when-text-is-RTL-LTR
Testing
Open the test app, go Android TextField Samples -> Basic input fields, write some LTR text in any textfield with RTL text, then try to select text. Selection Handles should be visible
Release Notes
Fixes - iOS
Google CLA
You need to sign the Google Contributor’s License Agreement at https://cla.developers.google.com/.
This is needed since we synchronise most of the code with Google’s AOSP repository. Signing this agreement allows us to synchronise code from your Pull Requests as well.