Status Update
No update yet.
Comments
ma...@google.com
First of all thanks for this detailed issue.
This issue had been investigated thoroughly when it was first reported internally. The surprising detail in this report is that the issue is not reproducible before 1.7. I will look into this.
The main problem with POBox is the fact that it is deprecated. Since 2021 Sony has been shipping new Xperia devices with Gboard pre-installed. Although we are aware that there is still a considerable amount of users still using POBox, the described behavior is caused by POBox's noncompliant behavior with InputConnection and InputMethodManager documentation. However, this is understandable since TextView implementation was also not respecting the behavior that is expected from Editors.
Ultimately we have decided to enforce the documented behavior with specifically regards to when editors should call InputMethodManager.updateSelection. Also, although unconfirmed, there were traces of possible custom code being included in Sony OEM images that changed how InputMethodManager was notified from TextView. If POBox also depended on something like this, it would be impossible for Compose code to replicate the same unknown behavior.
mo...@google.com
Or is that option not available?
Even if the root cause is POBox, from the perspective of the app's customers, it looks like an app bug, so this issue is a blocker against updating Jetpack Compose.
mo...@google.com
Just to be sure, it is dangerous to replace Compose TextField with Android View EditText as a workaround for this issue.
Compose 1.7 has a bug that causes ANR when the focus is on EditText.
Another View-related bug in Compose 1.7 is that an Android View is focused by calling FocusManager.clearFocus().
Perhaps there is a lack of testing of Compose 1.7 in combination with Android View. There is also a possibility that there are other fatal bugs related to View.
In other words, the only options for apps targeting the Japanese market that require POBox support are to continue using Compose 1.6 or to use EditText in combination with various workarounds.
ma...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Halil Ozercan <
Link:
Fix POBox keyboard issue
Expand for full commit details
Fix POBox keyboard issue
Fix: 373743376
Fix: 329209241
Test: NullableInputConnectionWrapperTest
Change-Id: I94e0e598274fb88b255f977f9fbd50dfbbb1ecb1
Files:
- M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/text/input/NullableInputConnectionWrapperTest.kt - M
compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/text/input/NullableInputConnectionWrapper.android.kt
Hash: 57f58c4b80d5d8470b2aca325dfdcd55f235231e
Date: Thu Oct 24 01:25:20 2024
st...@google.com
Many thanks again for this report. Especially for giving us a huge clue in terms of what could be going wrong. The fix is now merged and I will ask for a cherry-pick into a stable release.
le...@google.com
Do you have any concrete plan to cherry-pick the fix into current stable version (1.7.x)? We are currently waiting it.
ap...@google.com
Yes, this fix is planned to be included in a future 1.7.x release.
le...@google.com
ap...@google.com
Thanks for the fix. Sorry to follow up on this. is it possible for you to share specific release version/date for the stable version? We are waiting on this to decide on our direction.
le...@google.com
ap...@google.com
Branch: androidx-main
commit 4e1e7aa76fe04d05362fa5cc319bd490401dfa61
Author: Levi Albuquerque <levima@google.com>
Date: Thu Jun 09 13:47:56 2022
Improvements on how to calculate velocity based on pointer position
In this CL I updated the way we add data from an InputEventChange into
the velocity tracker. Now we add points deltas instead of event positions.
This will guarantee that points are consistent even if the target element
is moving, which was not considering when adding the input event position.
Test: Added tests to check the behaviour in scrolling.
Fixes: 216582726
Bug: 223440806
Bug: 227709803
Relnote: "When adding InputEventChange events to Velocity Tracker we will
consider now deltas instead of positions, this will guarantee the velocity
is correctly calculated for all cases even if the target element moves"
Change-Id: Icea9d76a43643a6b17da11f3c539d27cb8fa6f6e
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/lazy/list/LazyListTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/ScrollableTest.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/input/pointer/util/VelocityTracker.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/lazy/list/BaseLazyListTestWithOrientation.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/input/nestedscroll/NestedScrollModifierTest.kt
to...@undo.app
They were reverted 5 weeks ago.
The fling behaviour is still not working properly in this scenario:
ViewParent (MotionLayout) holding ComposeView (LazyColumn)
The release-notes details in 1.3.0-alpha01 (
"When adding InputEventChange events to Velocity Tracker we will consider now deltas instead of positions,
this will guarantee the velocity is correctly calculated for all cases even if the target element moves (If9ef3,
Can you provide an example of how this achieved in the scenario previously described?
Regards,
Toby.
le...@google.com
Hi Toby, thanks for reaching out about this. It seems there has been an issue with the release notes and they were not removed for the previous version. Since this change was merged on June 26th, it didn't make the cut for 1.3.0-alpha01. I'd expect it to come in the next release though, so stay tuned :)
to...@undo.app
Do you have an ETA for the next release?
le...@google.com
Hi Toby, the changes are available on 1.3.0-alpha03, let me know if this fixes your issue.
to...@undo.app
I am still not getting the expected behaviour.
When I do a fling on the list (LazyColumn), the parent view (MotionLayout) does not respond properly to this.
The Motionlayout only responds correctly when I am dragging the list.
When I try to fling the list it does not respond correctly. It either stops transitioning between the MotionLayout states or the transition between the two states is not done fluently.
I've been able to set up the same scenario, that has worked perfectly, with a RecyclerView instead of a ComposeView holding LazyColumn.
I've set up the LazyColumn with rememberNestedScrollInteropConnection().
It is set up like this.
binding.list.setContent {
LazyColumn(
state = listState,
modifier = Modifier
.fillMaxWidth()
.nestedScroll(rememberNestedScrollInteropConnection())
) {
items(listItems) {
......
}
}
}
The list is being set up in a MotionLayout (XML) via a ComposeView
<androidx.compose.ui.platform.ComposeView
android:id="@+id/list"
android:layout_width="0dp"
android:layout_height="0dp"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="@id/listTopGuideline"/>
The scene for MotionLayout has two constraint sets: "Start" and "End" where it should transition the listTopGuideline
app:layout_constraintGuide_percent from 0.59 to 0.1
<OnSwipe
app:dragDirection="dragUp"
app:touchAnchorId="@id/list" />
......
// Start ConstraintSet
<Constraint
android:id="@+id/listTopGuideline"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="horizontal"
app:layout_constraintGuide_percent="0.59" />
.....
// End ConstraintSet
<Constraint
android:id="@+id/listTopGuideline"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="horizontal"
app:layout_constraintGuide_percent="0.1" />
le...@google.com
Hi Tobias, thanks for reporting this. This seems like an interop issue between Compose and MotionLayout, could you open a different ticket for this? This ticket was related to velocity tracker in Modifier.draggable and I'm not sure the two are connected. Thanks!
Description
Issue
TLDR; watch the attached video.
Was trying to make a free flowing bottom sheet like view, that allows for the sheet content to also be scrollable.
Was able to create this using
.draggable()and a nested scroll connection.Drags are working fine. But flings aren't, when the sheet is still moving. Because the fling velocity being reported in
NestedScrollConnection.onPreFling()is wrong. Sometimes even in the opposite direction, if not the wrong magnitude.Root Cause
I suspect this is because the velocity calculation is based on touch position relative to the component handling the pointer input.
Documentation of
PointerInputChangestatesModifier.draggablewhich is also used inModifier.scrollableeffectively usesVelocityTracker.addPointerInputChange()Potential Fix
If
PointerInputChangealso hadabsolutePositionwhich is relative to the window/screen, and the above function is modified to useabsolutePositioninstead ofposition(relative), then we will see the right velocity being calculated when drag has stoppedI am not sure if we will need relative velocity of the user's fling to the component anywhere. It should be safe to move the implementation
VelocityTracker.addPointerInputChange()to useabsolutePositionalways.Other components that are affected (currently working around it)
Because of this issue, even
Swipeable.ktdoesn't use fling velocity to infer the direction of swipe, instead uses the diff of current offset and last offset -Attachments