IssueTracker

I understand the need for multiple onFocusChanged { ... } modifiers, but I don't see how multiple focusModifier()s would work.

I tried it out and if I use:

Modifier
.onFocusChanged(firstFn)
.focusModifier()
.onFocusChanged(secondFn()
.focusModifier()

only firstFn is called. I see that if both would be called, that would enable abstracting and passing around groups of .onFocusChanged {}.focusModifier() pairs.

On the other hand this code:

Modifier
.onFocusChanged(firstFn)
.onFocusChanged(secondFn()
.focusModifier()

calls both functions and still allows for onFocusChanged's to be passed around, and I think this is valuable. In this case the behavior is also quite straight forward: The onFocusChanged need to be followed by a .focusModifier() to be active.

Did I miss some use case you had in mind for multiple focus modifiers?

I can't think of an actual use-case for multiple focusModifiers per layout node, but the nature of our system allows the addition of multiple focus modifiers. So this is not a realistic scenario, but if we want to make your example work, you would need another focus requester. Focus requesters are similar to onFocusChanged modifiers. Both of them request/observe the next focusModifier. Your example could be changed to:

Modifier
   .focusRequester(focusRequester1)
   .onFocusChanged { ... }
   .focusModifier()
   .border(10.dp)
   .focusRequester(focusRequester2)
   .onFocusChanged { ... }
   .focusModifier()

Now, calling focusRequester1.requestFocus() will change the state of the first focusModifier. focusRequester2.requestFocus() will change the state of the second focusModifier.

I guess the way to think of it is that the focus state is part of the focus modifier. When you call requestFocus(), the focusModifier's state is changed to "focused".

Thank you for the explanation! I tried that out and it meets expectations. One thing to note is that the platform provided d-pad navigation brings focus to the first focusRequester.

Oh, I didn't realize that you were using the d-pad. Yes, the d-pad will bring focus to the first focus modifier. You can think of the second modifier as a child of the first, imagine they were defined across different composables:

@Composable
fun FancyFocusableBox(){
   FocusableBox(Modifier
       .onFocusChanged {...}
       .focusModifier()
   )
}

@Composable
fun FocusableBox(modifier: Modifier){
   Box(modifier
       .onFocusChanged {...}
       .focusModifier()
   )
}

So coming back to your example, the d-pad will initially bring focus to the first modifier. If you then press d-pad center, focus will move to the next modifier.

Updated the documentation. Closing this bug.