IssueTracker

George, is this correct: You think this should not be a layout API but focus API?

The reason why I thought it is a layout API is the fact that it is a layout related View API in android independent of the focus management.

It is being used by focus on EditText, but it also is not 1-1 related to focus. For example it is possible that as a developer I'd like to show different components for a tutorial as the user clicks on next on my tutorial (I guess this was an example given on the chat)

FYI: Happy to implement this one if you can guide me on where to start, or how to do it.

OK, I have to admit that I made a mistake while reading. I saw the platform prefix and in the top-left of that page and thought this was a View method that we were overriding.

Stream of consciousness here:

It looks like notifyFocusedRect() is intended to call requestRectangleOnScreen(). This is a layout system API, not a focus system API.

I think we have some of what you need already in public API. What you're looking for is the bounding box of a Layout, right? To get this, look at LayoutCoordinates.boundsInRoot().

I think the thing you're looking for is the actual requestRectangleOnScreen() equivalent, right? I don't know if we want to expose it as an arbitrary rectangle or if we want to expose it as applying to an entire LayoutCoordinates. My initial thought is that any LayoutCoordinates is sufficient and an easier API to work with. I would recommend that we start with that API and see how much need there is to request an arbitrary rectangle on the screen.

I haven't looked at the implementation of requestRectangleOnScreen() but I imagine that there is a lot of setting scroll positions. We will have to set scroll positions of scrollables in the hierarchy. There's currently no way for a scrollable to interact with the layout system in a way that allows the layout system to provide feedback to scrollable.

Matvei, do you have any suggestions here? Can the layout system poke a scrollable to change its scroll position?

If it isn't possible (my initial thought), then we have to interact at a higher level of abstraction, using the nested scrolling interface to bring a rectangle on screen. Maybe something like this:

fun NestedScrollDispatcher.requestBringOnScreen(coordinates: LayoutCoordinates)

It looks like the nested scrolling is implemented in NestedScrollDelegatingWrapper, so it may be possible to have:

fun LayoutCoordinates.requestBringOnScreen()

Assigning to Matvei for his input.

Bumping this ticket as it's coming up very regularly in #Compose chat.

Use cases that developers are hitting regularly.

• TextField in a LazyColumn is not visible after keyboard shows, even if scrolling would allow it to be visible
• TextField in a scrollable Column is not visible after keyboard shows, even if scrolling would allow it to be visible

One workaround (in app code) is to save the layout position for the TextField then manually scroll a ScrollState.

Coming back to this to give me 5 cents.

Modifier.scrollable itself doesn't have any notion of layout at all, so I'm unsure if that would be the right place for it. Thing to node is that we also need to provide a proper nestedscroll support (+ account for nested scroll as well, as you want your toolbar to collapse if the textField is below the soft input, don't you?).

It seems like we would need to account for that in the scrollable implementations, e.g Modifier.verticalScroll or LazyColumn, as they also might want to process it differently. Some bits might live in the Modifier.scrollable as well, but it's mostly a layout thing I suppose.

Another alternative: could it be possible to utilise semantics for this purpose? I don't know how idiomatic it would be but it seems like it is somewhat related. WE could basically ask whatever container to scroll to the bounds (which we could retrieve from the layout node) and the scroll bit will just work out of the box if the semantics are set right.

Ralston, let me know if you need any help or input from the scrolling side! Thanks!

Bulk edit: This bug is currently marked as blocking Compose 1.0. Once rc01 is cut, all changes will need to go through our cherry-pick process.

If you intend to fix it in Compose 1.0, no action is needed except prioritizing finishing this work.

Otherwise, please remove this bug from the appropriate 1.0 hotlist (likely Jetpack Compose 1.0 (May 2021)) and add it to Post-1.0 (or not-yet-prioritized).

Thanks!

For this fix we need TextField to use RelocationRequester.bringIntoView() which is an experimental UI API, and it so it can't be fixed for Compose 1.0

Is there something that has to be done from the developer perspective for the textfield to scroll into view when the keyboard comes up to cover them?