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

This has been fixed internally in

https://android-review.googlesource.com/870975 and will be available in Navigation 1.0.0-alpha10.

Now, instead of crashing, we ignore invalid deep links, printing a log message saying as much.

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

Hi team.
The problem still occurs on version 2.2.0-rc04

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

Hi, still getting crash for 2.1.0

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

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

Marked as fixed.

still getting crash on version 2.2.0

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

getting crash with 2.2.1

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

still getting crash with 2.2.1

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

findInvalidDestinationDisplayNameInDeepLink always return null if deepLink length == 1 (deep link destination is start destination of any navGraph of BottomNavigationView)

NavDestination node = i == 0 ? mGraph : graph.findNode(destinationId);
if deepLink.length == 1 node never will be null and this will cause IllegalStateException

Bug demo:

get NavigationAdvancedSample from github

on R.id.about_btn click

NavDeepLinkBuilder(it.context)
.setGraph(R.navigation.list)
.setDestination(R.id.leaderboard)
.createTaskStackBuilder()
.startActivities()

will crash because R.id.leaderboard is start destination (findInvalidDestinationDisplayNameInDeepLink will have deepLink length == 1)

NavDeepLinkBuilder(it.context)
.setGraph(R.navigation.list)
.setDestination(R.id.userProfile)
.createTaskStackBuilder()
.startActivities()

will work because findInvalidDestinationDisplayNameInDeepLink will return NOT null

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

It still crash with the latest version 2.2.1. I think the problem lies somewhere around this code

NavDestination node = i == 0 ? mGraph : graph.findNode(destinationId);

When i is 0, just return mGraph itself. When the deep link destination is a root of bottom_nav tab, the deeplink.length becomes 1. Which means this function still says there's no invalid Destination in deep link even if deepLink[0] is totally irrelevant tomGraph.

So this step passes and when findDestination() is actually triggered down the road, it won't find any destination and thus lead to unknown destination crash.

All NavControllers of bottom nav automatically call handleDeepLink() as part of onGraphCreated(). The problem arises the moment NavController whose graph is irrelevant to the root deep link destination calls handleDeepLink().