IssueTracker

Which API level are you seeing the issue here with?

My hunch is that this is related to https://android-review.git.corp.google.com/c/platform/frameworks/support/+/2293199, since using a DialogFragment or ComponentDialog adds a new Window that the contained ComposeView is not aware of.

I've only tested this on API level 33 and 26 so far, and out of these two I'm seeing this only on 33

Experiencing the same issue. Slowly migrating the project to compose and i still need the some compose views to be inside a DialogFragment.

Faced the same and like #3 mentioned, compose switched to use a DialogWindowProvider to figure out its window.

To workaround it in the meantime I copied ComposeView and made it report my dialog window. Not easy, but you cant get past creating a subclass.

internal abstract class ComposeBottomSheetFragment : BottomSheetDialogFragment() { // Can be simple DialogFragment

  @Composable protected abstract fun Content()

  override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
    return ComposeDialogView(requireContext()).also {
      it.consumeWindowInsets = false
      it.layoutParams = LayoutParams(MATCH_PARENT, WRAP_CONTENT)
      it.setContent {
        OurTheme { Content() }
      }
    }
  }

  // Copy of ComposeView that is able to supply the dialog window to compose.
  // I used inner class but you can also pass a lambda to the view and lazily request the window
  inner class ComposeDialogView(context: Context) : AbstractComposeView(context, null, 0), DialogWindowProvider {


    // The important bit
    override val window get() = requireDialog().window!!

    private val content = mutableStateOf<(@Composable () -> Unit)?>(null)

    override var shouldCreateCompositionOnAttachedToWindow: Boolean = false
      private set

    @Composable
    override fun Content() {
      content.value?.invoke()
    }

    override fun getAccessibilityClassName(): CharSequence = ComposeView::class.java.name

    /**
     * Set the Jetpack Compose UI content for this view.
     * Initial composition will occur when the view becomes attached to a window or when
     * [createComposition] is called, whichever comes first.
     */
    fun setContent(content: @Composable () -> Unit) {
      shouldCreateCompositionOnAttachedToWindow = true
      this.content.value = content
      if (isAttachedToWindow) createComposition()
    }
  }

  private var ComposeDialogView.consumeWindowInsets: Boolean
    get() = getTag(androidx.compose.ui.R.id.consume_window_insets_tag) as? Boolean ?: true
    set(value) {
      setTag(androidx.compose.ui.R.id.consume_window_insets_tag, value)
    }
}

That workaround should work, due to this line: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/text/input/InputMethodManager.kt;l=159;drc=16ad8c080ac1284a39ca331e4a6169646b82e62a

Only seeing this issue on API 30 and above also makes sense, due to the underlying mechanics.

I tested with the stable 1.4.0 version, having the same problem.

The solution in #7 causes NPE at times when used with DialogFragment. Not sure how to get around it, seems to be a timing issue since it is not occurring 100 % of the time. Is there a way to guarantee that the dialog window exist when onCreateView is called?

It looks like in my case that it tries to fetch the window to close the soft keyboard after the dialog window has disappeared

java.lang.NullPointerException
at com.xyz.compose.ComposeDialogFragment$windowProvider$2$1.getWindow(ComposeFragment.kt:101)
at com.xyz.compose.ComposeDialogFragment$ComposeDialogView.getWindow(Unknown Source:2)
at androidx.compose.ui.text.input.ImmHelper30.findWindow(InputMethodManager.kt:159)
at androidx.compose.ui.text.input.ImmHelper30.getInsetsControllerCompat(InputMethodManager.kt:133)
at androidx.compose.ui.text.input.ImmHelper30.hideSoftInput(InputMethodManager.kt:152)
at androidx.compose.ui.text.input.InputMethodManagerImpl.hideSoftInput(InputMethodManager.kt:83)
at androidx.compose.ui.text.input.TextInputServiceAndroid.setKeyboardVisibleImmediately(TextInputServiceAndroid.android.kt:397)
at androidx.compose.ui.text.input.TextInputServiceAndroid.processInputCommands(TextInputServiceAndroid.android.kt:302)
at androidx.compose.ui.text.input.TextInputServiceAndroid.sendInputCommand$lambda$1(TextInputServiceAndroid.android.kt:209)
at androidx.compose.ui.text.input.TextInputServiceAndroid.$r8$lambda$tFIm8sXGny3G873nGUe23EJe7OY(Unknown Source:0)
at androidx.compose.ui.text.input.TextInputServiceAndroid$$ExternalSyntheticLambda0.run(Unknown Source:2)
at androidx.compose.ui.text.input.TextInputServiceAndroid_androidKt.asExecutor$lambda$1$lambda$0(TextInputServiceAndroid.android.kt:504)
at androidx.compose.ui.text.input.TextInputServiceAndroid_androidKt.$r8$lambda$RYljF3nl5HRu6JKEM8xFRHwbGFg(Unknown Source:0)
at androidx.compose.ui.text.input.TextInputServiceAndroid_androidKt$$ExternalSyntheticLambda0.doFrame(Unknown Source:2)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1229)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1239)
at android.view.Choreographer.doCallbacks(Choreographer.java:899)
at android.view.Choreographer.doFrame(Choreographer.java:827)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1214)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7872)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)

Any progress on this issue? Seems like it breaks a lot of things, I can't migrate to 1.4

There is any plan about which version is the bug fix planned to be released in?

The plan is to release this with Compose 1.4.2 (and next 1.5.0 alpha) later this week, and it's corresponding BOM versions.

Thanks for the explanation, so the BOM versions will also be updated within a month (like 2023.04.xx)? If so, that will be great!

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.compose.foundation:foundation:1.4.2
• androidx.compose.ui:ui:1.4.2

Tested with code provided in #5. Tapping the TextField in the dialog opens the keyboard on Compose 1.4.2 ok. What are you observing? Maybe you can share your min repro? TY.

Hi,

keyboard was shown properly in compose 1.4.3 but in 1.5.0-alpha03 it stopped working again.

In 1.4.3 and 1.5.0-alpha03 now i have following issue which causing app crash.

1 @main: CRASH DETECTED on thread Thread[main,5,main]
 E  java.lang.IllegalStateException: LayoutCoordinate operations are only valid when isAttached is true
 E  	at androidx.compose.ui.node.NodeCoordinator.localToRoot-MK-Hz9U(NodeCoordinator.kt:850)
 E  	at androidx.compose.foundation.text.TextFieldDelegate$Companion.notifyFocusedRect$foundation_release(TextFieldDelegate.kt:173)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt.notifyFocusedRect(CoreTextField.kt:1111)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt.notifyTextInputServiceOnFocusChange(CoreTextField.kt:962)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt.access$notifyTextInputServiceOnFocusChange(CoreTextField.kt:1)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt$CoreTextField$focusModifier$1.invoke(CoreTextField.kt:293)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt$CoreTextField$focusModifier$1.invoke(CoreTextField.kt:282)
 E  	at androidx.compose.ui.focus.FocusChangedModifierNode.onFocusEvent(FocusChangedModifier.kt:59)
 E  	at androidx.compose.ui.focus.FocusEventModifierNodeKt.refreshFocusEventNodes(FocusEventModifierNode.kt:68)
 E  	at androidx.compose.ui.focus.FocusTransactionsKt.requestFocusForChild(FocusTransactions.kt:208)
 E  	at androidx.compose.ui.focus.FocusTransactionsKt.performRequestFocus(FocusTransactions.kt:69)
 E  	at androidx.compose.ui.focus.FocusTransactionsKt.requestFocus(FocusTransactions.kt:44)
 E  	at androidx.compose.ui.focus.FocusRequester.focus$ui_release(FocusRequester.kt:72)
 E  	at androidx.compose.ui.focus.FocusRequester.requestFocus(FocusRequester.kt:63)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt.tapToFocus(CoreTextField.kt:939)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt.access$tapToFocus(CoreTextField.kt:1)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt$CoreTextField$pointerModifier$1.invoke-k-4lQ0M(CoreTextField.kt:342)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt$CoreTextField$pointerModifier$1.invoke(CoreTextField.kt:341)
 E  	at androidx.compose.foundation.text.TextFieldPressGestureFilterKt$tapPressTextFieldModifier$1$2$2.invoke-k-4lQ0M(TextFieldPressGestureFilter.kt:81)
 E  	at androidx.compose.foundation.text.TextFieldPressGestureFilterKt$tapPressTextFieldModifier$1$2$2.invoke(TextFieldPressGestureFilter.kt:54)
 E  	at androidx.compose.foundation.gestures.TapGestureDetectorKt$detectTapAndPress$2$1.invokeSuspend(TapGestureDetector.kt:255)
 E  	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
 E  	at kotlinx.coroutines.DispatchedTaskKt.resume(DispatchedTask.kt:178)
 E  	at kotlinx.coroutines.DispatchedTaskKt.dispatch(DispatchedTask.kt:166)
 E  	at kotlinx.coroutines.CancellableContinuationImpl.dispatchResume(CancellableContinuationImpl.kt:397)
 E  	at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl(CancellableContinuationImpl.kt:431)
 E  	at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$default(CancellableContinuationImpl.kt:420)
 E  	at kotlinx.coroutines.CancellableContinuationImpl.resumeWith(CancellableContinuationImpl.kt:328)
 E  	at androidx.compose.ui.input.pointer.SuspendingPointerInputModifierNodeImpl$PointerEventHandlerCoroutine.offerPointerEvent(SuspendingPointerInputFilter.kt:672)
 E  	at androidx.compose.ui.input.pointer.SuspendingPointerInputModifierNodeImpl.dispatchPointerEvent(SuspendingPointerInputFilter.kt:548)
 E  	at androidx.compose.ui.input.pointer.SuspendingPointerInputModifierNodeImpl.onPointerEvent-H0pRuoY(SuspendingPointerInputFilter.kt:570)
 E  	at androidx.compose.ui.input.pointer.Node.dispatchMainEventPass(HitPathTracker.kt:314)
 E  	at androidx.compose.ui.input.pointer.Node.dispatchMainEventPass(HitPathTracker.kt:301)
 E  	at androidx.compose.ui.input.pointer.Node.dispatchMainEventPass(HitPathTracker.kt:301)
 E  	at androidx.compose.ui.input.pointer.Node.dispatchMainEventPass(HitPathTracker.kt:301)
 E  	at androidx.compose.ui.input.pointer.Node.dispatchMainEventPass(HitPathTracker.kt:301)
 E  	at androidx.compose.ui.input.pointer.Node.dispatchMainEventPass(HitPathTracker.kt:301)
 E  	at androidx.compose.ui.input.pointer.NodeParent.dispatchMainEventPass(HitPathTracker.kt:183)
 E  	at androidx.compose.ui.input.pointer.HitPathTracker.dispatchChanges(HitPathTracker.kt:102)
 E  	at androidx.compose.ui.input.pointer.PointerInputEventProcessor.process-BIzXfog(PointerInputEventProcessor.kt:98)
 E  	at androidx.compose.ui.platform.AndroidComposeView.sendMotionEvent-8iAsVTc(AndroidComposeView.android.kt:1371)
 E  	at androidx.compose.ui.platform.AndroidComposeView.handleMotionEvent-8iAsVTc(AndroidComposeView.android.kt:1323)
 E  	at androidx.compose.ui.platform.AndroidComposeView.dispatchTouchEvent(AndroidComposeView.android.kt:1263)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at com.android.internal.policy.DecorView.superDispatchTouchEvent(DecorView.java:500)
 E  	at com.android.internal.policy.PhoneWindow.superDispatchTouchEvent(PhoneWindow.java:1905)
 E  	at android.app.Dialog.dispatchTouchEvent(Dialog.java:911)
 E  	at androidx.appcompat.view.WindowCallbackWrapper.dispatchTouchEvent(WindowCallbackWrapper.java:70)
 E  	at com.android.internal.policy.DecorView.dispatchTouchEvent(DecorView.java:458)
 E  	at android.view.View.dispatchPointerEvent(View.java:15262)
 E  	at android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent(ViewRootImpl.java:6654)
 E  	at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:6454)
 E  	at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5910)
 E  	at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5967)
 E  	at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5933)
 E  	at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:6098)
 E  	at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5941)
 E  	at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:6155)
 E  	at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5914)
 E  	at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5967)
 E  	at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5933)
 E  	at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5941)
 E  	at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5914)
 E  	at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:8996)
 E  	at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:8947)
 E  	at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:8916)
 E  	at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:9119)
 E  	at android.view.InputEventReceiver.dispatchInputEvent(InputEventReceiver.java:267)
 E  	at android.os.MessageQueue.nativePollOnce(Native Method)
 E  	at android.os.MessageQueue.next(MessageQueue.java:335)
 E  	at android.os.Looper.loopOnce(Looper.java:161)
 E  	at android.os.Looper.loop(Looper.java:288)
 E  	at android.app.ActivityThread.main(ActivityThread.java:7872)
 E  	at java.lang.reflect.Method.invoke(Native Method)
 E  	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
 E  	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
 E  	Suppressed: kotlinx.coroutines.DiagnosticCoroutineContextException: [androidx.compose.ui.platform.MotionDurationScaleImpl@a05fbf2, androidx.compose.runtime.BroadcastFrameClock@67c3243, StandaloneCoroutine{Cancelling}@d0400c0, AndroidUiDispatcher@76f01f9]

Steps to reproduce should be quite simple. Just create some BottomSheetDialogFragment which will have compose view inside and in that compose view you should have some TextInputs. Also im using FocusRequester in that compose screen.

In compose 1.4.3 - keyboard was shown properly when i clicked into text inputs there BUT if i clicked on some input which was partially hidden under keyboard it caused crash (see stacktrace above). In compose 1.5.0-alpha03 - keyboard is not showing when i clicked into some text input - instead it will just do that crash (see stacktrace above).

This issue occur on Samsung S23 and also on emulator.

I think its related to https://issuetracker.google.com/issues/215116019

Please act urgently and increase this ticket priority because its important issue. Thanks

P1 since it is reported to be a regression.

First, prioritizing this as a regression for 1.5 and adding to burndown list. Lets get this sorted.

Second, the fix in this bug is only included in:

• Patch release: 1.4.3
• Alpha release: 1.5.0-alpha04

It was not included in 1.5.0-alpha03 as it didn't make the release cut.

In compose 1.4.3 - keyboard was shown properly when i clicked into text inputs there BUT if i clicked on some input which was partially hidden under keyboard it caused crash (see stacktrace above).

Thank you!

Can you share a minimal repro against 1.4.3 or 1.5.0-alpha04 with repro steps help expedite the fix.

Thanks!

I tried version 1.5.0-alpha04 - keyboard is shown properly in that dialog but there is still that crash below (but its related to https://issuetracker.google.com/issues/215116019 i guess). Currently im able to reproduce that issue when i have multiple textinputs in that dialog - i click on first input, keyboard is shown up, i click into last one textinput, then i click into first input again and crash occur.

 E  	at androidx.compose.ui.node.NodeCoordinator.localToRoot-MK-Hz9U(NodeCoordinator.kt:844)
 E  	at androidx.compose.foundation.text.TextFieldDelegate$Companion.notifyFocusedRect$foundation_release(TextFieldDelegate.kt:173)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt.notifyFocusedRect(CoreTextField.kt:1111)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt.notifyTextInputServiceOnFocusChange(CoreTextField.kt:962)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt.access$notifyTextInputServiceOnFocusChange(CoreTextField.kt:1)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt$CoreTextField$focusModifier$1.invoke(CoreTextField.kt:293)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt$CoreTextField$focusModifier$1.invoke(CoreTextField.kt:282)
 E  	at androidx.compose.ui.focus.FocusChangedModifierNode.onFocusEvent(FocusChangedModifier.kt:59)
 E  	at androidx.compose.ui.focus.FocusEventModifierNodeKt.refreshFocusEventNodes(FocusEventModifierNode.kt:68)
 E  	at androidx.compose.ui.focus.FocusTransactionsKt.requestFocusForChild(FocusTransactions.kt:208)
 E  	at androidx.compose.ui.focus.FocusTransactionsKt.performRequestFocus(FocusTransactions.kt:69)
 E  	at androidx.compose.ui.focus.FocusTransactionsKt.requestFocus(FocusTransactions.kt:44)
 E  	at androidx.compose.ui.focus.FocusRequester.focus$ui_release(FocusRequester.kt:72)
 E  	at androidx.compose.ui.focus.FocusRequester.requestFocus(FocusRequester.kt:63)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt.tapToFocus(CoreTextField.kt:939)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt.access$tapToFocus(CoreTextField.kt:1)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt$CoreTextField$pointerModifier$1.invoke-k-4lQ0M(CoreTextField.kt:342)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt$CoreTextField$pointerModifier$1.invoke(CoreTextField.kt:341)
 E  	at androidx.compose.foundation.text.TextFieldPressGestureFilterKt$tapPressTextFieldModifier$1$2$2.invoke-k-4lQ0M(TextFieldPressGestureFilter.kt:81)
 E  	at androidx.compose.foundation.text.TextFieldPressGestureFilterKt$tapPressTextFieldModifier$1$2$2.invoke(TextFieldPressGestureFilter.kt:54)
 E  	at androidx.compose.foundation.gestures.TapGestureDetectorKt$detectTapAndPress$2$1.invokeSuspend(TapGestureDetector.kt:255)
 E  	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
 E  	at kotlinx.coroutines.DispatchedTaskKt.resume(DispatchedTask.kt:178)
 E  	at kotlinx.coroutines.DispatchedTaskKt.dispatch(DispatchedTask.kt:166)
 E  	at kotlinx.coroutines.CancellableContinuationImpl.dispatchResume(CancellableContinuationImpl.kt:397)
 E  	at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl(CancellableContinuationImpl.kt:431)
 E  	at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$default(CancellableContinuationImpl.kt:420)
 E  	at kotlinx.coroutines.CancellableContinuationImpl.resumeWith(CancellableContinuationImpl.kt:328)
 E  	at androidx.compose.ui.input.pointer.SuspendingPointerInputModifierNodeImpl$PointerEventHandlerCoroutine.offerPointerEvent(SuspendingPointerInputFilter.kt:670)
 E  	at androidx.compose.ui.input.pointer.SuspendingPointerInputModifierNodeImpl.dispatchPointerEvent(SuspendingPointerInputFilter.kt:546)
 E  	at androidx.compose.ui.input.pointer.SuspendingPointerInputModifierNodeImpl.onPointerEvent-H0pRuoY(SuspendingPointerInputFilter.kt:568)
 E  	at androidx.compose.ui.input.pointer.Node.dispatchMainEventPass(HitPathTracker.kt:317)
 E  	at androidx.compose.ui.input.pointer.Node.dispatchMainEventPass(HitPathTracker.kt:303)
 E  	at androidx.compose.ui.input.pointer.Node.dispatchMainEventPass(HitPathTracker.kt:303)
 E  	at androidx.compose.ui.input.pointer.Node.dispatchMainEventPass(HitPathTracker.kt:303)
 E  	at androidx.compose.ui.input.pointer.Node.dispatchMainEventPass(HitPathTracker.kt:303)
 E  	at androidx.compose.ui.input.pointer.Node.dispatchMainEventPass(HitPathTracker.kt:303)
 E  	at androidx.compose.ui.input.pointer.NodeParent.dispatchMainEventPass(HitPathTracker.kt:183)
 E  	at androidx.compose.ui.input.pointer.HitPathTracker.dispatchChanges(HitPathTracker.kt:102)
 E  	at androidx.compose.ui.input.pointer.PointerInputEventProcessor.process-BIzXfog(PointerInputEventProcessor.kt:96)
 E  	at androidx.compose.ui.platform.AndroidComposeView.sendMotionEvent-8iAsVTc(AndroidComposeView.android.kt:1376)
 E  	at androidx.compose.ui.platform.AndroidComposeView.handleMotionEvent-8iAsVTc(AndroidComposeView.android.kt:1328)
 E  	at androidx.compose.ui.platform.AndroidComposeView.dispatchTouchEvent(AndroidComposeView.android.kt:1268)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3121)
 E  	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2802)
 E  	at com.android.internal.policy.DecorView.superDispatchTouchEvent(DecorView.java:500)
 E  	at com.android.internal.policy.PhoneWindow.superDispatchTouchEvent(PhoneWindow.java:1905)
 E  	at android.app.Dialog.dispatchTouchEvent(Dialog.java:911)
 E  	at androidx.appcompat.view.WindowCallbackWrapper.dispatchTouchEvent(WindowCallbackWrapper.java:70)
 E  	at com.android.internal.policy.DecorView.dispatchTouchEvent(DecorView.java:458)
 E  	at android.view.View.dispatchPointerEvent(View.java:15262)
 E  	at android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent(ViewRootImpl.java:6654)
 E  	at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:6454)
 E  	at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5910)
 E  	at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5967)
 E  	at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5933)
 E  	at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:6098)
 E  	at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5941)
 E  	at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:6155)
 E  	at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5914)
 E  	at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5967)
 E  	at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5933)
 E  	at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5941)
 E  	at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5914)
 E  	at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:8996)
 E  	at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:8947)
 E  	at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:8916)
 E  	at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:9119)
 E  	at android.view.InputEventReceiver.dispatchInputEvent(InputEventReceiver.java:267)
 E  	at android.os.MessageQueue.nativePollOnce(Native Method)
 E  	at android.os.MessageQueue.next(MessageQueue.java:335)
 E  	at android.os.Looper.loopOnce(Looper.java:161)
 E  	at android.os.Looper.loop(Looper.java:288)
 E  	at android.app.ActivityThread.main(ActivityThread.java:7872)
 E  	at java.lang.reflect.Method.invoke(Native Method)
 E  	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
 E  	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
 E  	Suppressed: kotlinx.coroutines.DiagnosticCoroutineContextException: [androidx.compose.ui.platform.MotionDurationScaleImpl@dc5dd85, androidx.compose.runtime.BroadcastFrameClock@9c07da, StandaloneCoroutine{Cancelling}@96ff40b, AndroidUiDispatcher@c8872e8]```

Thanks, we've split the TextField bits of b/215116019 to b/281984756 please put future updates there.

From my testing it looks like the relevant keyboard ime for this ticket is now fixed, and a new bug (b/281984756) has surfaced that we are also tracking for 1.5 release.

I will close this ticket if the only issue currently is the crash caused by !isAttached which is now tracked in a new bug.

If anyone has a repro other than the following crash, please comment and will re-open.

Crash below now tracked in b/281984756

1 @main: CRASH DETECTED on thread Thread[main,5,main]
 E  java.lang.IllegalStateException: LayoutCoordinate operations are only valid when isAttached is true
 E  	at androidx.compose.ui.node.NodeCoordinator.localToRoot-MK-Hz9U(NodeCoordinator.kt:850)
 E  	at androidx.compose.foundation.text.TextFieldDelegate$Companion.notifyFocusedRect$foundation_release(TextFieldDelegate.kt:173)
 E  	at androidx.compose.foundation.text.CoreTextFieldKt.notifyFocusedRect(CoreTextField.kt:1111)

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.compose.material3:material3-android:1.2.0-alpha02

With Compose BOM Version 2024.02.00, the keyboard is still not showing in a DialogFragment, where ComposeView is used from within onCreateDialog with AlertDialog.Builder.setView as described in https://issuetracker.google.com/issues/194754697 .

bug still happen with compose bom version 2024.05.00

、、、

java.lang.NullPointerException: Attempt to invoke virtual method 'android.view.WindowInsetsController com.android.internal.policy.DecorView.getWindowInsetsController()' on a null object reference at com.android.internal.policy.PhoneWindow.getInsetsController(PhoneWindow.java:3930) at androidx.core.view.WindowInsetsControllerCompat$Impl30.<init>(WindowInsetsControllerCompat.java:613) at androidx.core.view.WindowInsetsControllerCompat.<init>(WindowInsetsControllerCompat.java:102) at androidx.compose.ui.text.input.ImmHelper30.getInsetsControllerCompat(InputMethodManager.kt:133) at androidx.compose.ui.text.input.ImmHelper30.hideSoftInput(InputMethodManager.kt:152) at androidx.compose.ui.text.input.InputMethodManagerImpl.hideSoftInput(InputMethodManager.kt:83) at androidx.compose.ui.text.input.TextInputServiceAndroid.setKeyboardVisibleImmediately(TextInputServiceAndroid.android.kt:397) at androidx.compose.ui.text.input.TextInputServiceAndroid.processInputCommands(TextInputServiceAndroid.android.kt:302) at androidx.compose.ui.text.input.TextInputServiceAndroid.sendInputCommand$lambda$1(TextInputServiceAndroid.android.kt:209) at androidx.compose.ui.text.input.TextInputServiceAndroid.$r8$lambda$tFIm8sXGny3G873nGUe23EJe7OY(Unknown Source:0) at androidx.compose.ui.text.input.TextInputServiceAndroid$$ExternalSyntheticLambda0.run(Unknown Source:2) at androidx.compose.ui.text.input.TextInputServiceAndroid_androidKt.asExecutor$lambda$1$lambda$0(TextInputServiceAndroid.android.kt:504) at androidx.compose.ui.text.input.TextInputServiceAndroid_androidKt.$r8$lambda$RYljF3nl5HRu6JKEM8xFRHwbGFg(Unknown Source:0) at androidx.compose.ui.text.input.TextInputServiceAndroid_androidKt$$ExternalSyntheticLambda0.doFrame(Unknown Source:2) at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1229) at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1239) at android.view.Choreographer.doCallbacks(Choreographer.java:899) at android.view.Choreographer.doFrame(Choreographer.java:827) at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1214) at android.os.Handler.handleCallback(Handler.java:942) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loopOnce(Looper.java:201) at android.os.Looper.loop(Looper.java:288) at android.app.ActivityThread.main(ActivityThread.java:7872) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)

、、、

This bug is still present in BOM 2024.10.00

I spoke too soon. It worked in an emulator, but didn't scroll up automatically on my physical pixel 6.

Yeah, when I read your post I thought that there were some fixes in the 1.1.0-RC01, but it doesn't work.

For what its worth. I spent the entire day trying out all of the solutions above with no luck.

If anyone can figure out how to put 20 field inputs in a column (either scrollable or LazyColumn) and you can hit the ImeAction.Next button and scroll through all the items... please let me know. =)

You have to do it manually. If you read my solution (comment 40) I calculated the exact amount of scroll needed based on the size of the single item, of the lazycolumn and of the keyboard. You can adapt the code to manually scroll of that amount when you hit the keyboard button

Bring Into View Requester takes a rect , I would like to give it offset , let's say there another composable that needs to be always visible above the IME like a footer with buttons like in text editor applications , Now that composable might come above the text field when staying above the IME and the current line user is writing is underneath that footer thingy ! I wish I could provide offsets and move the text field more into y direction than it needs to , as much needed for my footer to always by visible below the text field and above the IME

@si...@gmail.com OH! I thought your comment did handle the keyboard button. I guess I will give it another try. Not to give you more work... but if there any chance you could get a working repo of this up on github. Might be slightly easier to follow your code along there. I will try to give your idea a whirl when I get back to my desk.

RE #48... That looks like a different issue. The issue here is that when the ime slides into view, the textfield is not scrolled up and into view (so that you can see what you are typing) The issue that is fixed in 1.2 looks to be an issue where the cursor doesn't properly scroll out of view when you scroll. That issue is here: https://issuetracker.google.com/issues/208883748

Just came across this issue as well. BringIntoViewRequester() / bringIntoView() still broken for me in 1.2.0-alpha01

Only work with delay and even then only 1 time or after focusing different text fields first.

UGH!

The main issue was that notifyFocusedRect was only asking the view to show the rect, not using Compose's mechanism for this, BringIntoViewRequester.

There's also an issue specifically with lazy lists, where if the field is too low, when the IME shows it disposes the composition containing the field before it has a chance to be brought into view. Once this bug is fixed, the lazy list issue should be fixed once lazy lists are able to keep focused nodes in the composition even when scrolled out of view (b/195049010).

The fix involves implementing b/178211874.

Note this is similar, but I think different than b/190539358 because this one specifically applies to scrollable containers.

WIP CL that will eventually contain the fix: https://android-review.googlesource.com/c/platform/frameworks/support/+/1959647

For the record I do not think it was reported in this thread, but there's also a side case, where the scroll does work, but when the keyboard change it's size there's nothing happening. Like the GBoard, you click on a field it scroll, the keyboard is visible, then a top bar on the keyboard is shown with suggestions and it appears over of the field.

The investigation last week turned up a number of cases we weren't handling, and some were easier to fix than others. aosp/1964580 should fix cases where the soft input mode is ADJUST_PAN, but for ADJUST_RESIZE we need to implement a piece of focus infrastructure that doesn't exist yet (b/216842427) so it will take a bit longer to fix. aosp/1965577 is the WIP CL chain that should fix that one.

It is probably fixed in version 1.2.0-alpha03. Follow description below Bug fixes. Have someone tried it out?

I just tried it out. In a single text field it works now. But when I use for example two text fields and on IME action next on the first one I switch the focus to the next field via FocusRequester, the keyboards stays below the first text field and therefore hides the next one.

My assumption would have been that the keyboard would now automatically jump to the next, now focused field.

I guess the problem was partially fixed, tested on version version 1.2.0-alpha03.

Here are a few problems:

• The TextField does not get fully visible when using ImeAction (Previous or Next) and focusing in a TextField that is hidden under the keyboard
• The TextField does not get fully visible when the user types on the keyboard.
  • Considering the scenario that the TextField was visible when focused, and the user scrolls the screen and start typing while the focused TextField is hidden.

I think there is a mistake on the release note of 1.2.0-alpha03.

The release notes say that the behavior of adjustResize has been improved, but I think this is a mistake for adjustPan.

According to #55, we need to implement an API that doesn't exist yet to achieve the correct behavior with adjustResize, but that task still seems to be a WIP.

I actually tried it with the accompanist sample, but it only works well with adjustPan.

Added on 2022/03/02

I just looked at the release notes, and the description is now fixed. Thanks to the person who fixed it.

Concerning that workaround:

You can get rid of that hacky delay with an OnGlobalLayoutListener which will observe the actual IME rect size and will be triggered when the soft keyboard is fully visible.

A basic example could look like this:

val bringIntoViewRequester = remember { BringIntoViewRequester() }
val scope = rememberCoroutineScope()
val view = LocalView.current
DisposableEffect(view) {
    val listener = ViewTreeObserver.OnGlobalLayoutListener {
        scope.launch { bringIntoViewRequester.bringIntoView() }
    }
    view.viewTreeObserver.addOnGlobalLayoutListener(listener)
    onDispose { view.viewTreeObserver.removeOnGlobalLayoutListener(listener) }
}
OutlinedTextField(
    modifier = Modifier.bringIntoViewRequester(bringIntoViewRequester),
    ...
)

However additional view logic will be needed for it to work with multiple TextFields.

¯\_(ツ)_/¯

I'm currently using the following workaround :

@OptIn(ExperimentalFoundationApi::class)
// TODO Remove this workaround once they fix the issue
fun Modifier.bringIntoViewOnFocus(
    source: MutableInteractionSource? = null,
    extraOffset: Float = 0f,
): Modifier = composed {
    var layoutCoordinates by remember { mutableStateOf<LayoutCoordinates?>(null) }
    val requester = remember { BringIntoViewRequester() }
    val isKeyboardShown = LocalWindowInsets.current.ime.isVisible
    val isSourceFocused = source?.collectIsFocusedAsState()?.value ?: false
    val focusModifier = when (source) {
        null -> {
            val scope = rememberCoroutineScope()
            Modifier.onFocusEvent { state ->
                if (state.isFocused && isKeyboardShown) {
                    scope.launch {
                        requester.bringIntoView(layoutCoordinates, extraOffset)
                    }
                }
            }
        }
        else -> Modifier
    }
    if (isSourceFocused && isKeyboardShown) {
        LaunchedEffect(Unit) {
            requester.bringIntoView(layoutCoordinates, extraOffset)
        }
    }

    Modifier
        .onGloballyPositioned { layoutCoordinates = it }
        .bringIntoViewRequester(requester)
        .then(focusModifier)
}

@OptIn(ExperimentalFoundationApi::class)
private suspend fun BringIntoViewRequester.bringIntoView(
    coordinates: LayoutCoordinates? = null,
    offset: Float = 0f,
) {
    val position = coordinates?.size?.toSize()?.toRect()
    val adjusted = position?.copy(
        top = position.top + offset,
        bottom = position.bottom + offset
    )
    bringIntoView(adjusted)
}

You can pass in MutableInteractionSource or it will default to Modifier.onFocusEvent + an extra offset in case the bottom navigation gets in the way. I'm sure it's not the best solution but it seems to work ok. Usage :

val extraOffset = with(LocalDensity.current) {
    BottomHeight.toPx()
}
OutlinedTextField(
    value = "test",
    onValueChange = {  },
    modifier = Modifier.bringIntoViewOnFocus(extraOffset = extraOffset),
)

The method described in #70 seemed doesn't work if the Column has a verticalScroll in the modifier

I still have issue with 1.2.0-alpha05, ADJUST_PAN and Landscape Orientation :

@Composable
private fun Screen() {
    var textValue by remember {
        mutableStateOf("")
    }
    Surface(Modifier.fillMaxSize()) {
        Column(
            horizontalAlignment = Alignment.CenterHorizontally, verticalArrangement = Arrangement.Center,
            modifier = Modifier.fillMaxSize()
        ) {
            Text(
                text = "Title",
                style = MaterialTheme.typography.h4,
                textAlign = TextAlign.Start,
                modifier = Modifier
                    .fillMaxWidth()
                    .fillMaxHeight(0.3f)
            )
            Spacer(modifier = Modifier.height(4.dp))
            Text(
                text = "Text\nTwo line",
                style = MaterialTheme.typography.body2,
                textAlign = TextAlign.Start,
                modifier = Modifier
                    .fillMaxWidth()
                    .fillMaxHeight(0.2f)
            )
            Spacer(modifier = Modifier.height(16.dp))
            TextField(
                textStyle = MaterialTheme.typography.body2,
                value = textValue,
                onValueChange = {
                    textValue = it
                },
                modifier = Modifier
                    .fillMaxWidth()
                    .fillMaxHeight(),
                colors = TextFieldDefaults.textFieldColors(
                    backgroundColor = Color.Blue,
                    textColor = MaterialTheme.colors.onSurface,
                    focusedIndicatorColor = MaterialTheme.colors.onSurface,
                    unfocusedIndicatorColor = Color.Transparent,
                    cursorColor = MaterialTheme.colors.onSurface
                )
            )
        }
    }
}

Click on the TextField and the field will be behind the keyboard. Be sure to force the orientation in landscape :

<activity
            android:name=".MainActivity"
            android:configChanges="keyboardHidden|uiMode|screenSize|screenLayout|orientation|colorMode|density|fontScale|fontWeightAdjustment|keyboard|layoutDirection|locale|mcc|mnc|navigation|smallestScreenSize|touchscreen"
            android:exported="true"
            android:label="@string/app_name"
            android:launchMode="singleTop"
            android:screenOrientation="landscape"
            android:theme="@style/Theme.ComposeTextFieldLandscapeTest"
            android:windowSoftInputMode="adjustPan">

Is it expected or still a bug ? It works if we adjust a vertical padding on Column (basically if the TextField is small "enough", it will be displayed above the keyboard). Maybe the issue is that the field is too big to be displayed above so it doesn't "scroll" to it ?

I'll push my sample on Github if required.

What is the recommended workaround for this issue? I tried some of the ones posted above but it seems they have limitations and do not always work in my case.

The fix should be in for non-lazy column in 1.2.0-alpha06

As per https://developer.android.com/jetpack/androidx/releases/compose-foundation#1.2.0-alpha06

"TextFields will now be kept above the keyboard when they are focused and the keyboard is shown, when inside a non-lazy scrollable and the soft input mode is ADJUST_RESIZE. (I4a485, b/190539358, b/192043120, b/216842427)"

Compose status update: Please update the Status and Status Summary fields of this bug! (or Public Status/Public Status Summary)

1.2.0-alpha07 works for me even with WindowCompat.setDecorFitsSystemWindows(window, false) - I'm listening for insets in the activity and adding the ime ones as a bottom padding for the content FrameLayout findViewById(android.R.id.content).

My only question is how to specify an extra offset to scroll additionally when keyboard appears? Say you have a bottom navigation that may get in the way or implemented toolbar quick return pattern as the user scrolls and using offset on the scaffold content?

I can repro the case where adding newlines until the cursor goes below the IME does not cause a scroll, but that's a separate issue so I've filed it as b/229125238.

I can't repro the issue reported in #81. What device/android version/IME are you seeing this with?

Should I report #76 in another issue ? it still happens in 1.2.0-alpha07 ; basically the text still goes below the IME if the TextField is too large to be visible entirely in the Rect above the IME. I have a working sample in the comment.

Isn't that the same as b/229125238?

Ok I can repro #81 on my Pixel 3 – ADJUST_RESIZE, not fitting system windows. Will investigate.

Filed the issue in #81 as b/230756508.

This is unfair. Compose issues are getting worked on, and at a good pace (contrary to many AOSP core bugs).

This one was one of the more complex ones and I guess it was delayed due to priorities which to me seem more or less reasonable.

And Compose is very usable in production, we have already released several rather complex apps which use it extensively.

All issues we've run into with QA (including this one) were fixable with workarounds. Also Compose devs provide good support/advice on them in kotlinlang's slack #compose channel. And doing workarounds for Compose issues is a lot more easier/pleasant than doing ones for a View-based system.

Anyways, I think this is not the discussion for the issue tracker.

Powerful tools may come with a bit of a steep learning curve (and to be honest, Compose ain't all that hard), but once that's done, you benefit from amazing possibilities and powers.

Regarding bugs, I don't see how Compose is any more buggy than the View system. As with any complex project, bugs are simply inevitable. It is indeed a new thing, and may still need some work to mature, but that's why there's Compose/View interop.

I use Compose mainly and I barely have to fix anything. If I don't like a default behavior, I don't have to sift through a 1000-line Custom View Java file, but I can simply copy the underlying Composable function, which is usually very simple and easy to understand, and change whatever I want easily.

And yes, I've already produced some rather complex apps with Compose, and actually used it for some weird use cases that I think are simply too hard to be worth it with Views, and yet Compose helped me create them reliably and easily exactly as I wanted (and even more than I wanted) down to individual pixels and even the small nuances in animations, shapes, and behavior, with code that's maintainable, short, and dare I say it, beautiful.

And at the end of the day, if you don't like it, don't use it. Google did not force anyone to use Compose, and all of its hype is well-deserved, aired by the Android Developer community at large.

Anyways, this is not the place to fight over this. If you have anything to help with this specific issue, you're welcome to provide your feedback. Otherwise you can go on Twitter or Reddit and do destructive criticism as much as you please, while developers here are building the next big thing.

I don't have any updates about fixes yet, but I understand the frustration about this issue and it is definitely being worked on. It's not actually a P4 – the "Priority" field on buganizer is very misleading, it has a very specific internal meaning and interaction with other systems so we don't use it for actual prioritization for compose text issues. Unfortunately, the way we track actual priority is not visible externally.

I'm using 1.2.0-beta03 and trying to make this work for a TextField inside a Row.

Even while using one of the workarounds, the functionality doesn't work most of the time in landscape mode, and seems to not work in certain cases in portrait mode (perhaps when the keyboard pops up a second or later time and making certain types of edits).

@OptIn(ExperimentalFoundationApi::class, ExperimentalComposeUiApi::class)
@Composable
fun EnterText() {
    Row(
        modifier = Modifier
            .fillMaxWidth(),
        verticalAlignment = Alignment.CenterVertically,
        horizontalArrangement = Arrangement.Center,
    )
    {
        val relocation = remember { BringIntoViewRequester() }
        val scope = rememberCoroutineScope()
        var thoughts by rememberSaveable { mutableStateOf("") }
        TextField(
            value = thoughts,
            modifier = Modifier
                .weight(1f)
                .bringIntoViewRequester(relocation)
                .onFocusEvent {
                    if (it.isFocused) scope.launch { delay(300); relocation.bringIntoView() }
                },
            label = { Text(text = "Enter text") },
            keyboardOptions = KeyboardOptions(keyboardType = KeyboardType.Text),
            onValueChange = { newText ->
                thoughts = newText
            }
        )
    }
}

Nothing to announce yet, but we are working very actively on this.

Please try to fix this on Priority, as going for hit & trial several times with the code and even after that not getting the expected workable solution is frustrating.

Read the comment number 40. I use this workaround in production, with about 1M users.

I realized I never posted my workaround for this.

It's actually on an old version of Compose but used to work very reliably

    val relocationRequester = remember { RelocationRequester() }
    var focused by remember { mutableStateOf(false) }
    val ime = LocalWindowInsets.current.ime
    LaunchedEffect(focused) {
        if (focused) {
            var done = false
            while (!done) {
                if (ime.isVisible && !ime.animationInProgress) {
                    relocationRequester.bringIntoView()
                    done = true
                }
                delay(100L)
            }
        }
    }
    TextField(
        modifier = Modifier
                // ...
                .onFocusChanged { focused = it }
                // ...
    )

I'm not sure if it still works with latest version because I didn't need it in recent projects yet and I haven't been working on the other one for several months.

I first posted it in this slack conversation https://kotlinlang.slack.com/archives/CJLTWPH7S/p1625070469186300

Let's say I have a sticky footer (bottom navigation) , Now when I type the text field will go below the bottom navigation even though I want it to be above it , so please fix that as well !

#112 you think it's worth creating a new issue with a repro on that and we can link to this bug if they're related? just to add to the test cases to verify

#113 Yeah , great !

This code doesn't work when OutlinedTextField becomes Multiline in a simple scrollable column https://gist.github.com/wakaztahir/12145df72c53ebc6e1a6feca46fbc3bc#file-testtextfieldcompose-kt-L38

I have a question , Do I need to use BringIntoViewRequester or the textfield will be kept in view without me writing any code ? Like Do I need to do anything ?

Hi there. This issue is not dead, and it is not fixed in production yet. It remains high priority for us and we're actively working on fixing it. However it is caused by a very complex combination of dependencies and the fix is not trivial. We've most recently been focusing on https://issuetracker.google.com/issues/195049010 and https://issuetracker.google.com/issues/259274257 blocking this specific bug. https://issuetracker.google.com/241591211 is also related. TY.

Major fixes to this were just released in 1.4.0-alpha04. Text fields in lazy columns should work now too. One notable case that is still being worked on is if the text field is bigger than the available space.

You mean an OutlinedTextField? Can you share the snippet?

Can you please attach a video of BasicTextField still going under the IME? And repro code if possible.

Ah, that's https://issuetracker.google.com/237190748. Still working on that one.

I am getting the same crash , waiting for next release , please release that fast

Major fixes to this were just released in 1.4.0-alpha04

Major bugs were also released...

    java.lang.NoSuchFieldError: No static field $stable of type I in class Landroidx/compose/foundation/text/KeyboardActions; or its superclasses (declaration of 'androidx.compose.foundation.text.KeyboardActions' appears in /data/app/~~xxx/base.apk)
        at androidx.compose.material3.TextFieldKt$TextField$5.invoke(TextField.kt:343)
        at androidx.compose.material3.TextFieldKt$TextField$5.invoke(TextField.kt:323)
        at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:107)
        at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:34)
        at androidx.compose.runtime.CompositionLocalKt.CompositionLocalProvider(CompositionLocal.kt:228)
        at androidx.compose.material3.TextFieldKt.TextField(TextField.kt:323)

The crash above is reported here with workaround: https://issuetracker.google.com/265172081#comment2 , TY

so I upgraded to material 3 alpha04 and now I am not getting the Crash BUT I am still getting the text field going under the keyboard , I will post a video about it My TextField does take full width , is multiline but unless the user presses enter , it remains single lined , When I tap on the text field , the keyboard comes from underneath and stays on top of the field I don't use BringIntoViewRequester or any other code to bring it into view , I expect it to work magically.

Can you confirm you're also using Foundation version 1.4.0-alpha04? The bug was fixed in Foundation, not Material, and while material3 1.1.0-alpha04 should be using the latest alpha, I just want to make sure it actually is in your project. A video would be helpful, thanks.

I created a sample project and recorded this video , apparently the keyboard is opening and text field staying above when I tap on the field but not for long , when the text field becomes multiline , the text goes below keyboard

This project using latest compose version

1.1.0-alpha04 for material 3

Compose version 1.4.0-alpha04 , UI , which should probably including foundation of the same version

https://github.com/wakaztahir/captain-text-field

That's also https://issuetracker.google.com/237190748.

So if I apply a fixed height , would it work ?

Actually I think this might be a separate bug, since the resized field isn't internally scrollable. I filed b/266094055 to track.

We are closing this issue since the main case for this bug has been fixed: fixed-size text fields inside scrollable Columns and LazyColumns will be kept above the keyboard when they gain focus and the keyboard becomes shown and would otherwise cover the field.

There are still some cases related to this that are still broken and being worked on, but those will be tracked in separate bugs going forward. The known remaining issues at this time are:

• Cursors in text fields that take all available space and are internally scrollable may disappear behind the keyboard (b/237190748)
• Text fields that grow taller while being edited aren’t kept above the keyboard (b/266094055)
• Crash with “No field $stable of type I in class Landroidx/compose/foundation/text/KeyboardActions” (b/265172081)
• Text fields will stay below the keyboard when inside LazyVerticalGrid (b/265352893)

Please follow those individual bugs for further updates.

If you find new issues, please file new bugs instead of commenting here.