TextField in Jetpack Compose 1.7 Does Not Support Japanese Input Correctly with POBox IME on Xperia Devices [373743376]

Fixed

Bug

Status Update

No update yet.

Description

y-...@unext.jp

created issue #1

Oct 16, 2024 03:58AM

Environment:

Jetpack Compose version: 1.7.3
Jetpack Compose component(s) used: TextField
Android Studio Build: Android Studio Koala Feature Drop | 2024.1.2 Patch 1
Kotlin version: 2.0.20
Devices: Xperia 1, Xperia ZL2, Xperia XZ2 Premium
IME: POBox Plus

Issue Summary:
In Jetpack Compose 1.7, when using the POBox IME on Xperia devices, certain Japanese characters such as small characters (e.g., "っ", "ゃ", "ゅ", "ょ") and diacritic marks (dakuten, handakuten) cannot be input into a TextField. Additionally, toggle input (e.g., pressing 'あ' multiple times to switch to 'い', 'う', etc.) does not work as expected.

Steps to Reproduce or Code Sample to Reproduce:

Use a Sony Xperia device with the POBox IME.
Open a Jetpack Compose 1.7 app that contains a TextField.
Attempt to input Japanese characters using a Japanese keyboard (IME), including small characters (e.g., "っ", "ゃ", "ゅ", "ょ") and diacritic marks (dakuten, handakuten), as well as toggle input (e.g., pressing 'あ' multiple times to change it to 'い', 'う', etc.).

For a detailed demonstration of the issue, please refer to the attached reproduction video.

Actual Results:

Small characters like "っ" (small tsu) and "ゃ, ゅ, ょ" (small ya, yu, yo) cannot be entered.
Diacritic marks (dakuten and handakuten) cannot be added to characters.
Toggle input does not work. For example, pressing 'あ' three times should result in 'う', but instead results in 'あああ'.

Expected Results:

Users should be able to input small characters like "っ", "ゃ", "ゅ", "ょ".
Diacritic marks (dakuten and handakuten) should be added properly when required.
Toggle input should function correctly, allowing users to change characters by repeatedly pressing the same key (e.g., 'あ' -> 'い' -> 'う').

Reproduction Rate:

100%
This issue occurs every time under the described conditions.

Environment:

This issue happens regardless of the Android OS version.
The problem occurs specifically on Xperia devices using the POBox IME when Jetpack Compose 1.7's TextField is used.
Jetpack Compose 1.6 does not exhibit this issue.

Additional Information:

According to our investigation, POBox is pre-installed on Xperia devices up to the Xperia 1, released in 2019 (https://www.sony.jp/xperia/xperia/xperia1/?srsltid=AfmBOoox1BTdp0e7TprBv0hcGsft9wxrpNf_-KepPYoCqf6QgXX6axE1). As a result, this issue could affect a significant number of Android users in Japan.

While we suspect the issue may be related to the combination of Xperia devices and POBox, we would greatly appreciate your investigation into a potential solution or workaround within Jetpack Compose.

Workaround Attempted:

As a workaround for this issue, we attempted to directly use EditText within AndroidView by utilizing ViewBinding in the Compose environment. However, we encountered another issue in our project that prevented us from using this workaround effectively.

It would be greatly appreciated if you could also prioritize investigating and addressing this issue. Here is the link to the related issue:
https://partnerissuetracker.corp.google.com/issues/369354336#comment4

Sample App to Reproduce:
You can reproduce the issue using this app:
https://github.com/yurihondo/screentransitionsample

Please especially check the implementation at the following location:
https://github.com/yurihondo/screentransitionsample/blob/c71e4d6f41c76cdeb8a359e3cc6938a5250ac5da/feature/applepie/src/main/java/com/yurihondo/screentransitionsample/applepie/EditRoute.kt#L76

reproduction_video_by_sample_app.mp4

4.1 MB

Download

Comments

jo...@google.com <jo...@google.com> Oct 18, 2024 10:37AM

Reassigned to ha...@google.com.

ha...@google.com <ha...@google.com> #2Oct 21, 2024 10:02PM

Still crashing with Compose 1.7.4.
I also tried moving sharedElement to BoxWithConstraints (rather than in its content), but did not help.
So the layout hierarchy looks like this (with more details and with "..." I replaced series of "normal" layouts):
NavHost -> ... -> AnimatedVisibility -> ... -> BoxWithConstraints with sharedElement -> some content
\> ... -> AnimatedVisibility -> ... -> LazyList -> ... -> Animated Visibility -> Selection container -> BoxWithConstraints with sharedElement -> some content

Any ideas?

ma...@gmail.com <ma...@gmail.com> #3Oct 22, 2024 11:27AM

In your BoxWithConstraints do you do any conditional composition? Things like:

if (constraintsExceedsCertainThreshold) composeSomeContent() else someOtherContent()

to...@gmail.com <to...@gmail.com> #4Oct 22, 2024 01:46PM

No, it's just a `Text` which has different style depending on constraints.
Also note `sharedElement` is put on `BoxWithContraints` now, not on the content.
Thanks!

Message last modified on Oct 22, 2024 01:49PM

ap...@google.com <ap...@google.com> #5Oct 24, 2024 01:19AM

Marked as fixed.

Based on the stacktrace, it seems like the item in question is composed but never placed. Do you use custom precompose or prefetch logic in your lazy list?

ha...@google.com <ha...@google.com> #6Oct 24, 2024 01:33AM

No, nothing custom. Just the default prefetch logic.
There is also one `AnimatedContent` above the `BoxWithConstraints`. Could this cause issues?
Thank you for looking into this.

ke...@mercari.com <ke...@mercari.com> #7Nov 7, 2024 06:56AM

The AnimatedContent never skips measuring/placing children after it composes them. So I don't expect that to be the issue.

Since you mentioned the modifier is on BoxWithConstraints rather than on the children of BoxWithConstraints, my guess is it's most likely related to LazyList.

Can you clarify what type of LazyList you are using? Is it LazyColumn/Row or LazyGrid, or something else?

ha...@google.com <ha...@google.com> #8Nov 7, 2024 12:05PM

Makes sense, thanks.
It's a LazyColumn.

ka...@mercari.com <ka...@mercari.com> #9Nov 22, 2024 02:11AM

One interesting observation is that this stack trace did not seem to come from the ComposeView with our app's Activity content. Because I did a release with copy pasted setContent + ComposeView subclass that is catching exceptions in dispatchDraw and it did not catch this crash. Is the animations framework doing content composition outside the app's composition context? One note: at the time I tried this exception catching, sharedElement was applied to the content of BoxWithConstraints (rather than to the BoxWithConstraints itself), but I don't think this would have caused the exception catching not to work.