IssueTracker

Project: platform/frameworks/support
Branch: androidx-main
Author: Louis Pullen-Freilich <lpf@google.com>
Link:      https://android-review.googlesource.com/3328184

Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling

Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling 
 
These APIs allow overscroll to have events dispatched to it by one component, and rendered in a separate component. 
 
Fixes: b/266550551 
Fixes: b/204650733 
Fixes: b/255554340 
Fixes: b/229537244 
Test: OverscrollTest 
Relnote: "Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling APIs - these APIs create a wrapped instance of the provided overscroll effect that doesn't draw / handle events respectively, which allows for rendering  overscroll in a separate component from the component that is dispatching events. For example, disabling drawing the overscroll inside a lazy list, and then drawing the overscroll separately on top / elsewhere." 
Change-Id: Idbb3d91546b49c1987a041f959bce4b2b09a9f61

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.compose.foundation:foundation:1.8.0-alpha06
• androidx.compose.foundation:foundation-android:1.8.0-alpha06
• androidx.compose.foundation:foundation-jvmstubs:1.8.0-alpha06
• androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-alpha06

I'm wondering how it will behave if you have a textfield taking up the whole screen (like Notes app). Will it scroll anyway?

It would depend on scrolling implementation we will implement (as far as I know we still didn't). I don't see a reason why it wouldn't scroll to the correct place (if the label does not take too much space).

One issue is showing the cursor. If we send the whole box, and if the TextField is too long (lets say 100 lines), then sending the whole box means that the cursor might not show up.

Maybe it is something we should take into account while implementing i.e. sending 2 rectangles:

• 1 for the box
• 1 for the cursor
• we try to show the box as a whole but we also try to make sure the cursor rectangle is visible (which means if the Textfield is 2 pages long, and the cursor is at the end, we lean towards the bottom half of the box; or if the cursor is at the begining we lean towards the top half of the box.
• this might be an edge case that we can check later as well.

I couldn't know the exact/correct answer right now :/

might be a P3 as well. I wanted to remove P4 since this is in our current list of tasks to do.

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!

Played a bit with one of the ideas: if the line being edited is not the last one, leave current behavior (i.e. show the cursor); otherwise use the decoration box bounds. In that case single line text field will always display padding/decoration box. In multi-line text field (Notes like app for example) we won't show the decoration box if not the last line is being edited.

Alternatively, I want to consider another option where we show the cursor and a bit more. I'll add more details when I played more with the idea.

We might need a UX input here.

Another point is that we need to make sure we request rectangle after editing, as currently we only do this on initial focus. As a result, when user types, the cursor becomes hidden behind the keyboard anyway.

Zach, this one is fixed, isn't it? Probably can be marked as duplicate

This isn't working yet because of b/216790855. I've confirmed that if I remove the inner bringIntoView call it works as expected.