Is `BringIntoViewRequester.bringIntoView()` suppos...

# compose

[vide]

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.

[vide]

Ah, the execution order of onFocusChanged callbacks might have changed in some version. It seems I'm actually calling bringIntoView before the FocusableNode does...

[vide]

It would be nice to have a way to disable the default behaviour 🤔

[Zach Klippenstein (he/him) [MOD]]

Please file a feature request

[vide]

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?

[Zach Klippenstein (he/him) [MOD]]

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

[Zach Klippenstein (he/him) [MOD]]

Maybe this could be disabled via a focus property? Cc @Ralston Da Silva

[vide]

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.

[vide]

Now that I think of it, this could probably be achieved by just defining a custom BringIntoViewResponderNode that allows not dispatching the same coordinates forwards to the parent Responder. This is prevented by all the related interfaces being internal, which I have actually already filed an issue about: https://issuetracker.google.com/issues/299939840

[vide]

> [e-mail] <[e-mail]> #2 2023-09-25 141209
> Thanks! We are discussing this feedback internally. It might be a while until this issue is updated.
😅

[vide]

I noticed @Ralston Da Silva commented on the issue so I created a changeset to kickoff discussion at least: https://android-review.googlesource.com/c/platform/frameworks/support/+/2803874
This is my/our first contribution attempt to AOSP/libraries so still unfamiliar with the process.

[vide]

Hi, I came back from vacation and back to this. Do I need to assign reviewers myself from the suggested owners?

[Zach Klippenstein (he/him) [MOD]]

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