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

Sure, I'll test it again and be back with the results tomorrow.

I indeed could not reproduce the issue in a "clean" environment anymore. However, within the app that I discovered the problem in, using an OutlinedTextField now resulted in a crash with the exception IllegalArgumentException: offset(1) is out of bounds [0, 0].

After a bit of experimentation, I discovered that this appears to be caused by the fact that the text field was used within a Dialog. That problem was reproducible even in a clean demo app, using

Dialog(onCloseRequest = {}) {
    Surface {
        var text = state { "" }

        OutlinedTextField(
                value = text.value,
                onValueChange = { text.value = it },
                label = { Text("Label") },
                modifier = Modifier.fillMaxWidth()
        )
    }
}

I'm not sure whether this crash arose as a result to changes around the prior issue (since they both seem to be related to selection bounds), or whether this is a different issue entirely. Should I create a new ticket for it or leave it here? If needed, I can provide a demo project, or a recording.

Thanks for coming back to us with the details.

Yes, the text field crashing inside a Dialog is a known bug that is fixed already. Please expect the fix to be available in the upcoming release.

Back to the original issue, since we couldn't reproduce it, I'm closing this bug. But please feel free to reopen this bug or file a new bug if you encounter any issues.

I apologize for the turnaround, but just as I was happy about the issue being gone, I managed to reproduce the original bug. I am not completely sure how fixable this is, though.

The difference between the real app and the test was that the textfield value was held and updated not by a regular Compose state, but by an external entity (in this case, MvRx). My guess is that MvRx doesn't always update its state immediately (when it does, it initiates a redraw of the View by itself). I think this state being out of sync is what's causing the issue. At least, I was able to reproduce the behavior by simulating a delayed view update from outside like this:

    object ExternalState {
        var text: String = ""
    }

    fun refreshView() {
        val handler = Handler()
        handler.postDelayed({
            (requireView() as ViewGroup).setContent(Recomposer.current()) {
                OutlinedTextField(
                        value = ExternalState.text,
                        onValueChange = {
                            ExternalState.text = it
                            refreshView()
                        },
                        label = { Text("Label") },
                        modifier = Modifier.fillMaxWidth()
                )
            }
        }, 10)
    }

It seems like I don't have permission to reopen the bug.

Andrey can you please check if you see something to do on the compose side? I do not know Rx.

I checked the sample code in comment#7 and did not understand what exactly is happening in the sample code. I do not have the setup and won't be able to check this bug in a real environment.

My guess is that MvRx doesn't always update its state immediately (when it does, it initiates a redraw of the View by itself). I think this state being out of sync is what's causing the issue.

Just based on the comment, if MvRx does not update its state it would be an MvRx & Compose conflict or MvRx issue. What is your suggestion to provide syncronization?

The delayed recompose does not fit to the current execution model of TF. TF expects the value to be set or not set; but not a delay. In the current case we can't handle delayed "resets" (since meanwhile user writes something and the new value is basically a reset).

Adam, Leland, I still need to read some documents but is this related to the current coroutine effort? If not do you have any opinions on how to solve the issue.

checked this. it is either not possible or not worth a change or trick with the current TextFieldValue API. We are planning to change that API and will consider this as a part of it.

Since there should be no major API changes anytime soon now, what's the status on this issue?

This still happens in Compose 1.3.0-alpha02, see duplicated issues for new steps and code (https://issuetracker.google.com/issues/240449669, https://issuetracker.google.com/issues/240455030)

This seems like a pretty big oversight as it makes validation of the text fields (such as preventing user from entering more than N characters) very bad experience for the user. And no responses since 2020...

This is easily worked around by using the constructor that takes a TextFieldValue as value, but should be fixed nonetheless.

I would be very interested in the reporter's "easy workaround" using the TextFieldValue constructor. How does that work? When I'm trying to use it, I'm only able to enter one char as a user and no more...

I hacked around the issue in the following way:

Before:

// asyncSource comes from the View Model and is changed via `changeText()`
OutlinedTextField(
    value = asyncSource.data,
    onValueChange = {
        viewModel.changeText(it)
    }
)

After:

// asyncSource comes from the View Model and is changed via `changeText()`
var inputText by remember(asyncSource.data) { mutableStateOf(asyncSource.data) }
OutlinedTextField(
    value = inputText,
    onValueChange = {
        inputText = it
        viewModel.changeText(it)
    }
)

I recognize that this is actually duplicating some of the logic, but I didn't have the jumping cursor issue anymore and still retain all flexibility of using asynchronous handling in my View Model and as a data source for the UI.

Hi, this is a 2020 bug which has undirectely been pointed out also in this -> https://medium.com/androiddevelopers/effective-state-management-for-textfield-in-compose-d6e5b070fbe5 article which actually cites the solution of the last user and is written by a Google spokeperson. It's a very spread one and impacts a LOT of developer and consequently a lot of user. It should be taken a little more seriously maybe. This fix is also not usable by kmm developers as pointed out inside a lot of comment of the above mentioned article and it's also very frustrating for people whose app has a lot or even more than 3 text fields.
Please, at least start to work on this issue.

Thanks for the comment.

The team already has started working on general structure of the TextField API since the current API and structure does not allow us to move forward with this ticket.

updated the assignee (one of Halil, Zach but can set only one), and also the priority to communicate that the work is ongoing in buganizer.

Yes, the work on this bug and related issues regarding TextField state was started a while ago. 1.5-alpha01 release includes some of this work.

It's unlikely that anything will be finalized in one release-cycle but the upcoming changes will be initially released as Experimental. So, the iterative changes won't be confined to alpha releases.

The solution in post #18 seems to work for me. Hoping this will be fixed soon officially.

Workarounds are outlined as per 18. The official solution is the new generation of TextField APIs which will be coming in future releases of Compose.

Comment 18 referenced this article: https://medium.com/androiddevelopers/effective-state-management-for-textfield-in-compose-d6e5b070fbe5

Closing this since async onValueChange updates are not supported and will continue to not be supported.

Yes: https://developer.android.com/jetpack/compose/text/user-input#state-practices

Also kind of implied by the kdoc but could be more clear.

It's also been explained in more detail in a few talks:

• around minute 26
• around minute 21

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

• androidx.compose.foundation:foundation:1.6.0-alpha08
• androidx.compose.foundation:foundation-android:1.6.0-alpha08
• androidx.compose.foundation:foundation-desktop:1.6.0-alpha08