Is

BringIntoViewRequester.bringIntoView()

supposed to cancel the previous animation? When moving focus to an off-screen element, I first get an animation automatically triggered by

FocusableNode.onFocusEvent

, and only after it has completed my own request (with a padded rect) is ran.

Please file a feature request

Is compose foundation open to external contribution? This sounds like like a P4 that will never get implemented if TV doesn't push it internally at Google. Might require some support still to match the global API design principles as there are several options: • API to disable sending the request at all at FocusableNode level: needs changes to focusable, clickable etc to pass configuration down to the Node • API to intercept bringIntoView calls before they reach the parent scrollable • API change to the responder in scrollable to only conditionally allow requests • something else?

We’re very open to external contributions, but as you note there’s a lot of design questions to answer.

I'll elaborate a bit on the use case here if that helps. I have a custom composable & modifier:

// simplified code but you should get the general idea
fun Modifier.scrollOnFocus(...) = Modifier.onFocusChanged { if (it.hasFocus) bringIntoViewRequester.bringIntoView(paddedRect) }
@Composable fun FocusableChunk() = Box(Modifier.scrollOnFocus().focusGroup()) { content() }

FocusableChunk can be then wrap any "sections" that should usually be visible at once if even one node inside it has focus, like a TV media row but more stuff in it. Currently it looks like onFocusChanged is called first for the parent (ActiveParent) before the activated node (Active) itself which makes timings difficult. The execution order might be unpredictable anyways as the calls are launched into coroutines.

We were in an api freeze for a while for the beta cut. We just got back into alpha, will take a closer look