IssueTracker

In the Gmail app for example (see image) the selection handle will get clipped to accommodate the selection, which is unlike what is happening here (see second image).

Can you please elaborate on the first sentence?

to Siyamed: Sure. This is basically what exploringbinary showed in their screenshots. the start handle selects the text based on its top right corner (where the sharp pointer edge is), so in order to select the text near the edge of the screen we have to essentially drag the handle out of screen bounds, so it's top right corner is at 0 x axis. I recommend to explore how we handle this case in the platform.

re screenshots: interestingly enough, your screenshots have a margin for a gmail, that's why it's possible. I assume we can clip the handle as well, but it won't help to solve the issue 100% since you won't be able to place the top right corner of the handle behind the screen.

got it thanks.

I don't know how much start padding Gmail uses but I tried 15.dp in my Compose example and it still does not help.

And while I'm here, looking at the Gmail vs Compose screenshot I'm reminded that I could really make use of a "Select all" feature in Compose :).

I believe this might require something else other than char based word based selection. the dup ticket might be one way of doing it however it may not solve the issue based on the video in b/178240897#comment19

I wonder if when selection handle approaches or touches the edge, it should actually horizontally transform, ( going from -> to <-, or from -> to |)

Therefore this might be a UX improvement and need UX input.

Qinginq, can you please describe how the dup ticket would help in this case?

(actually looking at the video in b/178240897#comment17) we already don't move beyond the screen edges right now; however we can't move the cursor left (as chrome does in the video b/178240897#comment19, and it is questionable if what Chrome does is ideal )

Just to make sure: the exact same behavior happens on android Text as well (handle disappearing completely). Is it correct?

Thank you very much Qingqing.

I retried the original example (as described in comment #1) on beta07. It works better, but not completely. If I select "text" in the first line and drag left, I can't always get "This". If I "fling" hard left and up I can sometimes get it (and I see the clipping of the handle). I did this on a Pixel 2 emulator and a Pixel 2 device.

As a slight variation of the problem, modify the example to replace line 1 ("This text is selectable") with one long word (I actually tried a number, "1234567890123456789") and 1) select it (that works) 2) drag the left handle right and release it somewhere within the number 3) try to drag left again and select the whole number (very hard to do). (If you don't release before dragging left it works.)

This issue shows up in my real app as well (I don't have zero padding, but I guess not "enough").

https://issuetracker.google.com/u/3/issues/187976146 also shows when I test this.

I still see this issue on beta09. I suppose I will have to file a new issue since this one is 'Fixed (Verified)'?

The behavior I described in comment #1 and comment #20 still exists on rc01. Should I write a new issue or can this one be reopened?

I've checked the framework TextView behavior and noticed a different handle drag behavior from Compose selection:

So in TextView when the left handle is at the word bound, dragging it left will extend the handle to the previous word boundary. Check the screen record attached. And this feature is helping user to selection the text at left boundary.

Also checked that Chrome has similar behavior. Now working on implement a similar behavior in Compose SelectionContainer.

The remaining work is more related to b/137322559. We will close this ticket for now and please check b/137322559 for more updates, thanks!