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.

one option we had was to revert the CL since it causes issues that we did not foresee.

• For example in the devrel chat Chris Banes was surprised that all the text they had was now centered
• it looks like the layout system aligns things by default to center but not to start (which on its own imho a little off)
• If a text contains paragraphs in RTL and LTR then they wont be correctly aligned. (not for this ticket, but a related note, I am very not confident about the layout direction, textdirection, text align changes we made.)

Let's revert the change. and think again.

Mihai, Andrei, since I lost the context a little can you please see the question in comment#9?

But Text is incorrectly reporting its size when we have not enough size available.

Text was not incorrectly reporting its size, it was complying with the given max/min widths. so they were correct from the Text perspective.

assigned to Andrey for comment#9

Thanks Andrey.

The clipping issue

• is something that I am aware of (the other components not clipping). As
• you also mentioned it is another problem.
• Let me create an issue for it.
• On Text side I am happy not to clip but it comes with problems of expectations.
  • TextOverflow currently have Clip, maybe it should have, and we should rely on modifiers (at the time we didnt have that)
  • or TextOverflow should still have None, where Text says ok, i won't clip it is up to developer (which I like better).
  • therefore we would be giving an option to developer to have more control on the clipping behavior.

The centering issue:

• Question:
  • When Image is given a larger width, does it scale? Does it comply?
• Specific to the change we made before:
  • We said Text should either comply or not comply for both width and height. If it accepts width to be larger (changing this cause trouble), then it should accept height to be larger.
  • Mihai mentioned that Text is different in the sense that there is a different relation with the width and height (width in height out). Therefore height can be special.

I wonder if this issue also requires a configuration. We changed the behavior and hit to a wall, if we had a configuration (through a modifier or a config option) it would be possible for a developer to enable the behavior you mentioned: Text will not comply with the rules, it will fit its box.

Lets keep this ticket open.

btw :)

Text("SEND", fontSize = 20.sp) Image(Icons.Default.Add, modifier = Modifier.size(60.dp))

Image gets a size. if Text had the same modifier Modifier.size(60.sp.toDp()) it would behave the same.

some notes from discussion with Mihai

• the option mentioned in coment#15 can be TextOverflow.None
• TextOverflow.Clip might not be needed for Compose (it came from CSS originally)
• TextOverflow can be [None, Ellipsis] (maybe later Fade) which cuts the text but not the drawing.
• When TextOverflow.None, developers use clip modifier.
• Open question: When TextOverflow.None, Text reports the real size (definitely height, don't know width) (fot width: think about softwrap)

for comment#17 we have created b/169217230

Will close this ticket, and postpone the mentioned ticket.