Status Update
Comments
ri...@google.com <ri...@google.com> #2
Branch: androidx-master-dev
commit 47ac9fee0e3d43b4da33f53b8a2ff590f0d46079
Author: Jakub Gielzak <jgielzak@google.com>
Date: Tue Aug 20 13:57:06 2019
Addressed issues with EditText causing scroll
EditText methods: bringPointIntoView, and handleFocusGainInternal
trigger requestChildRectangleOnScreen in ViewPager2's internal
RecyclerView.
This can cause:
- unwanted scrolling -- e.g. when typing on some API versions
- a jump to page 0 -- EditText sometimes reports over -1M px mScrollX
This fix bypasses requestChildRectangleOnScreen calculations taking
advantage of the fact that PagerSnapHelper constraints valid scroll
values to a snapped position ones, and as a result, the problem is
reduced to choosing the correct currentItem.
Bug: 138044582
Bug: 139432498
Test: ./gradlew viewpager2:connectedCheck
Change-Id: Ia4d3e4e6734183e64f261c7cc76d669deae78da5
A viewpager2/src/androidTest/java/androidx/viewpager2/widget/EditTextFocusTest.kt
M viewpager2/src/main/java/androidx/viewpager2/widget/ViewPager2.java
ri...@google.com <ri...@google.com> #3
ri...@google.com <ri...@google.com> #4
di...@gmail.com <di...@gmail.com> #5
That workaround works well for us, thanks a ton! Looking forward to the permanent fix.
ni...@parshipgroup.com <ni...@parshipgroup.com> #6
Are there any updates regarding this issue? We are still facing these crashes in our production app and it seems like the fix was never merged.
ek...@uber.com <ek...@uber.com> #7
We have also been continuing to see this in production. I've updated the sample in comment 0 to the latest BOM and still crashes. Any updates on the fix in the libraries?
ek...@uber.com <ek...@uber.com> #8
Bumping this thread again - the fix in
at...@netflix.com <at...@netflix.com> #9
sa...@google.com <sa...@google.com> #10
an...@google.com <an...@google.com> #11
Sorry, I should've abandoned that CL a while ago — we decided we didn't want to pursue that particular change for some subtle implications that it had.
I think we concluded that a better way to solve this issue on our end is to:
- Add a platform API to expose
ViewOverlay.OverlayViewGroup.mHostView
publicly - Add an appcompat API to backport the hostView property to older SDKs via reflection
- Update
findViewTreeLifecycleOwner()
to traverse the host view of a ViewOverlayGroup instead of its parent
ek...@uber.com <ek...@uber.com> #12
OK - Is that work planned for a future release then?
ek...@uber.com <ek...@uber.com> #13
Checking in on this bug since we're seeing high volumes in production and are considering rolling back Compose features.
an...@google.com <an...@google.com> #14
I've started working on the platform component of the bugfix I mentioned in
Once the androidx changes get published in a CL, they'll be linked here automatically and you can watch the progress more directly. The platform fixes are also technically linked here (see the Pending Code Changes in the right sidebar), but since they're in AOSP they won't be externally visible.
an...@google.com <an...@google.com>
do...@google.com <do...@google.com> #15
Just spoke with Andrew who informed me that the fix is well underway, and the hope is that it'll land within the next 6 weeks.
an...@google.com <an...@google.com> #16
Hey all, quick update here.
We've partially landed this fix. There's
In the short term: You will be able to receive this fix by upgrading to androidx.transition:transition:1.6.0-alpha01
when it is released (Probably in mid-December, but possibly in mid-January because of the upcoming US holidays). That will also upgrade androidx.core:core
to its latest version (which will probably be 1.16.0-alpha01
) and introduce a new dependency on androidx.core:core-viewtree:1.0.0-alpha01
, which is a new module we introduced as part of this change. You will not need to update any Compose dependencies to get the bug fix.
In the long term: We're planning to include a transitive dependency bump as part of the compose-ui 1.9.0 alphas. This bug will stay open until that happens. At some point, this will also work its way into a BOM, but I can't say when. We also can't include this in 1.8.0, unfortunately, because Compose is moving into beta soon, and beta libraries can't depend on core-viewtree
since it's in alpha currently.
ap...@google.com <ap...@google.com> #17
Project: platform/frameworks/support
Branch: androidx-main
Author: Andrew Bailey <
Link:
Set disjoint parents in transition overlays
Expand for full commit details
Set disjoint parents in transition overlays
Test: ComposeViewOverlayTest, in follow-up CL
Bug: b/340894487, b/287484338
Relnote: """
Transition now sets the disjoint parent for ViewOverlays used to
animate its transitions. This allows for the resolution of owners
through the disjoint parent, which means you can now correctly
resolve ViewModels, lifecycles, etc. during a transition.
"""
Change-Id: I10a16c84ba1efbf89a503418889ddd56bb711bed
Files:
- M
fragment/integration-tests/testapp/build.gradle
- M
navigation/integration-tests/testapp/build.gradle
- M
transition/transition-ktx/build.gradle
- M
transition/transition/build.gradle
- M
transition/transition/src/main/java/androidx/transition/GhostViewHolder.java
- M
transition/transition/src/main/java/androidx/transition/TransitionUtils.java
- M
transition/transition/src/main/java/androidx/transition/Visibility.java
Hash: b4846dbfd6e1e98421fe44d673965622fb5e66a4
Date: Wed Jul 31 09:56:27 2024
an...@google.com <an...@google.com> #18
androidx.transition:transition:1.6.0-alpha01
is included in today's androidx release. For everyone running into this issue, please upgrade your transition dependency to this version.
The next steps on our end are to bump the transition version that Compose UI depends on, which needs to wait until we bump the androidx-main branch to Compose 1.9.0-alpha01.
Bugjuggler: wait 2 months
Description
Jetpack Compose version: 1.4.3
Jetpack Compose component used: UI, ComposeView
Android Studio Build: Android Studio Hedgehog | 2023.1.1 Canary 8 Build #AI-231.9011.34.2311.10290408
Kotlin version: 1.8.10
Steps to Reproduce:
Visibility
Transition
in which the RecyclerView disappears.recyclerView.smoothScrollToPosition()
to reveal the off-screen ComposeView.Sample project attached. Click any item (without scrolling) to run.
I'm seeing this crash infrequently in a production app, and while we should probably avoid calling
smoothScrollToPosition()
on a view that we know is disappearing, this ideally wouldn't crash. Not sure if this is more an issue with RecyclerView or Compose.Stack trace: