TextField with readonly set to true can be edited [246909589]

Fixed

Bug

Status Update

No update yet.

Description

[Deleted User]

created issue #1

Sep 15, 2022 09:11AM

Jetpack Compose version: 1.2.1

Jetpack Compose component(s) used: androidx.compose.material.TextField

Android Studio Build:Android Studio Chipmunk | 2021.2.1 Build #AI-212.5712.43.2112.8512546, built on April 28, 2022

Kotlin version: 1.7.0

Steps to Reproduce or Code Sample to Reproduce:

1.Run this snippet 2.The TextField is enabled and not readonly for 10 seconds, you can start typing 3.When the 10 seconds have elapsed, the TextField can still be written to using the Virtual Keyboard

Is this a normal behavior? Is there another way to prevent writing to the TextField?

Sample code:

Surface(
                    modifier = Modifier.fillMaxSize(),
                    color = MaterialTheme.colors.background
                ) {
                    var text by remember { mutableStateOf("Hello") }
                    var readOnly by remember {
                        mutableStateOf(false)
                    }
                    LaunchedEffect(Unit) {
                        delay(Duration.seconds(10))
                        readOnly = true
                    }

                    TextField(
                        value = text,
                        onValueChange = { text = it },
                        label = { Text("Label") },
                        readOnly = readOnly,
                        enabled = !readOnly,
                    )
                }

textfield-bug-repro.mp4

1.3 MB

Download

Comments

lp...@google.com <lp...@google.com> Sep 15, 2022 02:21PM

Assigned to an...@google.com.

dm...@gmail.com <dm...@gmail.com> #2Jul 6, 2023 12:38PM

Thanks! This looks like a bug, thank you for reporting!

kl...@google.com <kl...@google.com> #3Jul 18, 2023 07:00PM

Reassigned to kl...@google.com.

I would also recommend setting the value to 10%. When you do that, the behavior is wild.

Dragging up to 10% or between 50% and 90% will cause it to snap back to the start anchor.
Dragging between 10% and 50% or past 90% will cause it to snap to the end anchor.

Message last modified on Jul 18, 2023 07:03PM

kl...@google.com <kl...@google.com> #4Jul 18, 2023 07:02PM

Comment has been deleted.

Message last modified on Jul 18, 2023 07:03PM

kl...@google.com <kl...@google.com> Jul 20, 2023 09:24PM

Accepted by kl...@google.com.

m....@anfe.ma <m....@anfe.ma> #5Jul 24, 2023 03:24PM

Any estimate on when will this release?

ap...@google.com <ap...@google.com> #6Jul 25, 2023 02:20PM

Marked as fixed.

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

androidx.compose.foundation:foundation:1.8.0-alpha04
androidx.compose.foundation:foundation-android:1.8.0-alpha04
androidx.compose.foundation:foundation-jvmstubs:1.8.0-alpha04

na...@google.com <na...@google.com> #7Aug 10, 2023 03:47PM

Using the new version 1.8.0-alpha04 does not seem to resolve the issue for me. I tested with the same setting as the reported issue:

            // it doesn't matter what you put here a the multiplier, the positionalThreshold is always 50%
            positionalThreshold = { d -> d * 0.9f },
            velocityThreshold = { Float.POSITIVE_INFINITY },

p....@anfe.ma <p....@anfe.ma> #8Aug 16, 2023 03:07PM

Same. I've run this again on 1.8.0-alpha04. When using

positionalThreshold = { d -> d * 0.1f }

Dragging up to 10% or between 50% and 90% will cause it to snap back to the start anchor. Dragging between 10% and 50% or past 90% will cause it to snap to the end anchor.

I would expect It to only return if dragged less than or equal to 10% and snap to the end if dragged greater than 10%.

When using

positionalThreshold = { d -> d * 0.9f }

It acts as if the threshold has been set to 50%.

From what I can tell, nothing has changed about the behavior.

se...@squareup.com <se...@squareup.com> #9Aug 29, 2023 12:08AM

Thanks, we will investigate and update this issue.

ek...@uber.com <ek...@uber.com> #10Aug 29, 2023 04:54PM

I can confirm that with version 1.8.0-alpha04. No matter what you pass to AnchoredDraggableDefaults.flingBehavior(positionalThreshold = {}) it is not respected.

kl...@google.com <kl...@google.com> #11Aug 29, 2023 06:21PM

Project: platform/frameworks/support
Branch: androidx-main
Author: Jossi Wolf <jossiwolf@google.com>
Link: https://android-review.googlesource.com/3343747

Update AnchoredDraggable target calculation logic

Expand for full commit details

Update AnchoredDraggable target calculation logic 
 
There was a missed case when the velocity was negative. 
 
Test: New tests with more parameter permutations 
Fixes: 367660226 
Bug: 376931805 
Relnote: "Follow-up fix for an issue in AnchoredDraggable's target calculation where it could settle at the wrong anchor for specific swipes." 
Change-Id: I23b8773d3a694aa3c8de6a8f34b9d7fb54cfe560

Files:

M compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/anchoredDraggable/AnchoredDraggableStateTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/AnchoredDraggable.kt

Hash: 6a23aa4ee37ba171475e4155db0d24c90b358c7e
Date: Fri Nov 08 14:11:31 2024

pr...@google.com <pr...@google.com> #12Sep 6, 2023 07:56PM

What is the fix version?