A modern programming language that makes developers happier.

kotlinlang

It seems there is yet another focus regression in compose-ui:1.4 :cold_sweat:
```E  java.lang.IllegalStateException: Check failed.
    [Full trace in thread]
   	at androidx.compose.ui.focus.FocusOwnerImpl.moveFocus-3ESFkO8(FocusOwnerImpl.kt:150)
   	at androidx.compose.ui.platform.AndroidComposeView$keyInputModifier$1.invoke-ZmokQxo(AndroidComposeView.android.kt:212)```

Full trace:
```E  java.lang.IllegalStateException: Check failed.
   	at androidx.compose.ui.focus.FocusTargetModifierNode.fetchFocusProperties$ui_release(FocusTargetModifierNode.kt:141)
   	at androidx.compose.ui.focus.TwoDimensionalFocusSearchKt.collectAccessibleChildren(TwoDimensionalFocusSearch.kt:216)
   	at androidx.compose.ui.focus.TwoDimensionalFocusSearchKt.findChildCorrespondingToFocusEnter--OM-vw8(TwoDimensionalFocusSearch.kt:121)
   	at androidx.compose.ui.focus.TwoDimensionalFocusSearchKt.twoDimensionalFocusSearch--OM-vw8(TwoDimensionalFocusSearch.kt:96)
   	at androidx.compose.ui.focus.FocusTraversalKt.focusSearch-sMXa3k8(FocusTraversal.kt:105)
   	at androidx.compose.ui.focus.FocusOwnerImpl.moveFocus-3ESFkO8(FocusOwnerImpl.kt:150)
   	at androidx.compose.ui.platform.AndroidComposeView$keyInputModifier$1.invoke-ZmokQxo(AndroidComposeView.android.kt:212)```

The specific check that fails is this:
```@ExperimentalComposeUiApi
internal inline fun DelegatableNode.visitAncestors(mask: Int, block: (Modifier.Node) -&gt; Unit) {
    // TODO(lmr): we might want to add some safety wheels to prevent this from being called
    //  while one of the chains is being diffed / updated. Although that might only be
    //  necessary for visiting subtree.
    check(node.isAttached)```

I haven't found out a reliable way to reproduce it which makes me think it's probably a race condition somewhere as the node is not attached anymore when running focus search :shrug:  This is a really big problem though for using 1.4.0

I have 2 stack traces of this and it seems like both involve `findChildCorrespondingToFocusEnter`, which might be a lead

I definitely will. I'm just hoping that gathering as much detail as possible would help the devs to narrow down the cause more effectively :blob-smile:

Also I don't think the description in the issue tracker is editable which might lead to some incoherent text if I notice something just after posting it :sweat_smile:

Both traces seem to have `twoDimensionalFocusSearch` in the stack only once, which to my understanding would indicate the focus search is beginning from the root of the hierarchy. I am not yet familiar with the Modifier Node architecture, but this would seem to indicate that the root node is for some reason detached from the layout :thinking_face:

There's no limit to follow-up comments though.  Trust me, over communication is never a bad thing when chasing down bugs

Here we go: <https://issuetracker.google.com/issues/274897776>