Calling Activity.setContentView again breaks recomposition of composables in the view hierarchy [197773820]

Fixed

Bug

Status Update

No update yet.

Description

lo...@gmail.com

created issue #1

Aug 26, 2021 10:51AM

Hello,

I found a bug that cost me one day to understand what triggers it, and I want to thank Adam Powell for helping me a bit to figure out what's going on.

TL;DR

In short, if you call setContentView with the same view hierarchy a second time after the initial render, the composables in the hierarchy will stop recomposing, which breaks/freezes everything in them.

Jetpack Compose release version: 1.1.0-alpha02 (also reproduces with 1.0 and 1.0.1)

Android Studio Build: irrelevant

Kotlin version: irrelevant

Reproducer

I attached a self-contained Kotlin file (MainActivity.kt) that reproduces the issue.

You can paste it in any Compose project over the existing MainActivity and try yourself.

However, I put below reproducing steps anyway.

Steps to Reproduce:

Create a ComposeView that displays a State that changes over time.
Put that instance into a local property.
Call setContentView passing that instance in the onCreate function of the host ComponentActivity.
Launch a coroutine in lifecycleScope
Call awaitFrame(), or delay(1500)
Call setContentView again, with the very same instance of the ComposeView created earlier.

Expected outcome

The composable keeps display the updates of the State instance.

Actual result

Once the setContentView is called the second time, the composable stops displaying the updates of the State instance.

The Slack thread from start to finish

If you want to see what was the process from facing the issue, to finding why it happened, you can take a look at this thread on Kotlin's Slack:

https://kotlinlang.slack.com/archives/CJLTWPH7S/p1629894233127300

What is likely the culprit IMHO

In the Android platform, the setContentView method in Activity is idempotent. Calling it a second time with the same view hierarchy while the Activity is not in the destroyed state will have no effect.

However, that contract seems to have been broken by the ComponentActivity class from AndroidX, as it's also calling a function named initViewTreeOwners().

The name of that function indicates that it's been designed for initialization, something which by definition, is supposed to happen only once. However, a setter doesn't generally have such constraints, at least, not because it's a setter (as the setContentView function is).

I think that this initViewTreeOwners() function being called again is what messes up ComposeView or its underlying mechanisms, putting them in a state they should not be in.

However, the issue might not be in ComponentActivity itself, but in the Compose runtime, or both.

Thanks for reading, and have a great day!

Louis CAD

MainActivity.kt

2.2 KB

Download

Comments

je...@google.com <je...@google.com> Aug 26, 2021 12:00PM

Assigned to ad...@google.com.

lo...@gmail.com <lo...@gmail.com> #2Aug 26, 2021 12:55PM

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.

ad...@google.com <ad...@google.com> #3Aug 27, 2021 09:11PM

Accepted by ad...@google.com.

If the investigation takes time, would it be possible to revert the surrounding implementation to 1.6.x equivalent?

Or is that option not available?

Even if the root cause is POBox, from the perspective of the app's customers, it looks like an app bug, so this issue is a blocker against updating Jetpack Compose.

lo...@gmail.com <lo...@gmail.com> #4Aug 27, 2021 10:17PM

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.

ap...@google.com <ap...@google.com> #5Oct 1, 2021 08:19PM

Marked as fixed.

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

Fix POBox keyboard issue

Expand for full commit details

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

Files:

M compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/text/input/NullableInputConnectionWrapperTest.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/text/input/NullableInputConnectionWrapper.android.kt

Hash: 57f58c4b80d5d8470b2aca325dfdcd55f235231e
Date: Thu Oct 24 01:25:20 2024

lo...@gmail.com <lo...@gmail.com> #6Feb 9, 2022 09:13PM

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.