IssueTracker

First of all thanks for this detailed issue.

This issue had been investigated thoroughly when it was first reported internally. The surprising detail in this report is that the issue is not reproducible before 1.7. I will look into this.

The main problem with POBox is the fact that it is deprecated. Since 2021 Sony has been shipping new Xperia devices with Gboard pre-installed. Although we are aware that there is still a considerable amount of users still using POBox, the described behavior is caused by POBox's noncompliant behavior with InputConnection and InputMethodManager documentation. However, this is understandable since TextView implementation was also not respecting the behavior that is expected from Editors.

Ultimately we have decided to enforce the documented behavior with specifically regards to when editors should call InputMethodManager.updateSelection. Also, although unconfirmed, there were traces of possible custom code being included in Sony OEM images that changed how InputMethodManager was notified from TextView. If POBox also depended on something like this, it would be impossible for Compose code to replicate the same unknown behavior.

Just to be sure, it is dangerous to replace Compose TextField with Android View EditText as a workaround for this issue.

Compose 1.7 has a bug that causes ANR when the focus is on EditText. https://issuetracker.google.com/issues/369354336

Another View-related bug in Compose 1.7 is that an Android View is focused by calling FocusManager.clearFocus(). https://issuetracker.google.com/issues/374031296

Perhaps there is a lack of testing of Compose 1.7 in combination with Android View. There is also a possibility that there are other fatal bugs related to View.

In other words, the only options for apps targeting the Japanese market that require POBox support are to continue using Compose 1.6 or to use EditText in combination with various workarounds.

Project: platform/frameworks/support
Branch: androidx-main
Author: Halil Ozercan <halilibo@google.com>
Link:      https://android-review.googlesource.com/3317256

Fix POBox keyboard issue

Fix POBox keyboard issue 
 
Fix: 373743376 
Fix: 329209241 
Test: NullableInputConnectionWrapperTest 
Change-Id: I94e0e598274fb88b255f977f9fbd50dfbbb1ecb1

Many thanks again for this report. Especially for giving us a huge clue in terms of what could be going wrong. The fix is now merged and I will ask for a cherry-pick into a stable release.

Yes, this fix is planned to be included in a future 1.7.x release.

Thanks for the fix. Sorry to follow up on this. is it possible for you to share specific release version/date for the stable version? We are waiting on this to decide on our direction.

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!