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

Thanks for reporting this! The intention here was for parentWidth to be hidden and it will be fixed soon. I see the potential convenience of exposing parentWidth and parentHeight, but in general it leads to a not very clean data flow: it would mean that after telling the layout system my size I receive the size back although my initial calculation is still in scope. I am afraid this would bring more confusion than convenience longer term. Just as a background, the reason we have parentWidth and not parentHeight is that it is needed to calculate horizontally mirrored positioning of children for layout direction RTL when placeRelative is used.

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

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 36b705d1dd148fc57e8089a94d485e0bfcd05d0f
Author: Mihai Popa <popam@google.com>
Date: Mon Sep 14 11:59:30 2020

Hide parentWidth and parentLD in PlacementScope

When writing a custom layout, parentWidth and parentLayoutDirection
should not be read from the placement block as they are available or
calculated in the measure block. This CL is making them protected in
PlacementScope. The CL also merges the PlacementScope implementations
used for modifiers and layout nodes, which is now possible after the
modules' merging.

Relnote: PlacementScope#parentWidth and PlacementScope#parentLayoutDirection can no longer be read from the placement block of a custom layout.
Fixes: 168295623
Test: tests in foundation-layout
Change-Id: Icc1ae00d774147c5fa7006c4bb408c99c7731690

M compose/ui/ui/api/current.txt
M compose/ui/ui/api/public_plus_experimental_current.txt
M compose/ui/ui/api/restricted_current.txt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/MeasureScope.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/Placeable.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/DelegatingLayoutNodeWrapper.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/LayoutNode.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/OuterMeasurablePlaceable.kt

https://android-review.googlesource.com/1426748

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

I actually found a reason for exposing both parentWidth and parentHeight in PlacementScope and that is modifiers. I wanted to write a modifier that places a composable using a percent which requires access to the parent's size. This currently does not seem possible using modifiers.

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

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

Marked as fixed.

Note that parentWidth was referring to the size of the current modifier (the same one returned when calling layout), not to the size of the parent. In general there would be a way to extend the layout system to provide the info you are looking for (the size of our parent when placing our children). However, I do not think this would be a good idea because modifiers relying on the parent size would not be nicely composable. I can write a modifier that positions children at a percentage of the parent but what if before me there is a modifier that offsets me? The percentage will not work anymore for my content.

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

Hmm. I see that as completely valid though. You might want to place it in the center but offset X a number of DP.

But I understand there might be other complexities. I was just surprised there was no way to write such a modifier today.

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

Thank you for fixing the issue, I confirmed the fix was released in version 1.8.0-alpha05.
Do you have any concrete plan to cherry-pick the fix into current stable version (1.7.x)? We are currently waiting it.

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

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

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

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.