IssueTracker

It is expected that BackHandler crashes in cases where no LocalOnBackPressedDispatcherOwner is provided.

Given that LocalOnBackPressedDispatcherOwner.current is nullable, you can certainly wrap your call to BackHandler in a null check if you'd like to specifically disable that functionality when in @Preview. Of course, you could just provide your own OnBackPressedDispatcherOwner by constructing an OnBackPressedDispatcher instance yourself as part of your @Preview.

Andrey - any thoughts on whether we should have @Preview automatically create and set a LocalOnBackPressedDispatcherOwner as we do for LocalViewModelStoreOwner? Who would be the correct assignee for that?

We've added default a LocalOnBackPressedDispatcherOwner and LocalActivityResultRegistryOwner to @Preview, so APIs that depend on these existing won't crash out of the box.

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!