Fixed
Status Update
Comments
jo...@google.com <jo...@google.com>
ha...@google.com <ha...@google.com> #2
Hi, thanks for reporting. Should be an easy fix!
I'm guessing it should work find until ~ 2^23 items = ~ 8M items. How did you come across this bug? Do you have a ViewPager2 with that many items?
I'm guessing it should work find until ~ 2^23 items = ~ 8M items. How did you come across this bug? Do you have a ViewPager2 with that many items?
ma...@gmail.com <ma...@gmail.com> #3
Hi, good to hear that.
We have an implementation of RecyclerView.Adapter that supports "infinite looping". So when the infinite looping is enabled, the adapter's getItemCount() reports Int.MAX_VALUE items. We also call setCurrentItem to somewhere in the middle of item count on the ViewPager2, so that's how we got that far.
We have an implementation of RecyclerView.Adapter that supports "infinite looping". So when the infinite looping is enabled, the adapter's getItemCount() reports Int.MAX_VALUE items. We also call setCurrentItem to somewhere in the middle of item count on the ViewPager2, so that's how we got that far.
to...@gmail.com <to...@gmail.com> #4
For future reference: first item for which it fails is probably when mCurrentItem = (1 << 25) + 2
ap...@google.com <ap...@google.com> #5
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 2e9f35536432bed0677171c8ae59b4f67850915a
Author: Jelle Fresen <jellefresen@google.com>
Date: Fri Jul 12 14:26:10 2019
Use double instead of float for decimal positions
A position ranges from 0 to Integer.MAX_VALUE, but floats only have a 23
bit mantissa. Values over 2^23 are rounded to a nearby value.
Solve this by using double instead of float when we need to represent a
position with a fractional component. A double has a mantissa of 52 bit
and can therefore represent all 2^32 possible int values.
Bug: 134858960
Test: ./gradlew viewpager2:cC
Change-Id: I08b97df6fac600caa83366ccab8671541e2c1e7f
A viewpager2/src/androidTest/java/androidx/viewpager2/test/ui/SparseAdapter.kt
M viewpager2/src/androidTest/java/androidx/viewpager2/widget/FakeDragTest.kt
M viewpager2/src/androidTest/java/androidx/viewpager2/widget/OffscreenPageLimitTest.kt
M viewpager2/src/androidTest/java/androidx/viewpager2/widget/PageChangeCallbackTest.kt
M viewpager2/src/androidTest/java/androidx/viewpager2/widget/PageTransformerTest.kt
M viewpager2/src/androidTest/java/androidx/viewpager2/widget/SetItemWhileScrollInProgressTest.kt
M viewpager2/src/main/java/androidx/viewpager2/widget/ScrollEventAdapter.java
M viewpager2/src/main/java/androidx/viewpager2/widget/ViewPager2.java
https://android-review.googlesource.com/1014538
https://goto.google.com/android-sha1/2e9f35536432bed0677171c8ae59b4f67850915a
Branch: androidx-master-dev
commit 2e9f35536432bed0677171c8ae59b4f67850915a
Author: Jelle Fresen <jellefresen@google.com>
Date: Fri Jul 12 14:26:10 2019
Use double instead of float for decimal positions
A position ranges from 0 to Integer.MAX_VALUE, but floats only have a 23
bit mantissa. Values over 2^23 are rounded to a nearby value.
Solve this by using double instead of float when we need to represent a
position with a fractional component. A double has a mantissa of 52 bit
and can therefore represent all 2^32 possible int values.
Bug: 134858960
Test: ./gradlew viewpager2:cC
Change-Id: I08b97df6fac600caa83366ccab8671541e2c1e7f
A viewpager2/src/androidTest/java/androidx/viewpager2/test/ui/SparseAdapter.kt
M viewpager2/src/androidTest/java/androidx/viewpager2/widget/FakeDragTest.kt
M viewpager2/src/androidTest/java/androidx/viewpager2/widget/OffscreenPageLimitTest.kt
M viewpager2/src/androidTest/java/androidx/viewpager2/widget/PageChangeCallbackTest.kt
M viewpager2/src/androidTest/java/androidx/viewpager2/widget/PageTransformerTest.kt
M viewpager2/src/androidTest/java/androidx/viewpager2/widget/SetItemWhileScrollInProgressTest.kt
M viewpager2/src/main/java/androidx/viewpager2/widget/ScrollEventAdapter.java
M viewpager2/src/main/java/androidx/viewpager2/widget/ViewPager2.java
ke...@mercari.com <ke...@mercari.com> #7
Thank you for fixing the issue, I confirmed the fix was released in version 1.8.0-alpha05.
Do you have any concrete plan to cherry-pick the fix into current stable version (1.7.x)? We are currently waiting it.
Do you have any concrete plan to cherry-pick the fix into current stable version (1.7.x)? We are currently waiting it.
ha...@google.com <ha...@google.com> #8
Yes, this fix is planned to be included in a future 1.7.x
release.
ka...@mercari.com <ka...@mercari.com> #9
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.
Description
Environment:
Issue Summary:
In Jetpack Compose 1.7, when using the POBox IME on Xperia devices, certain Japanese characters such as small characters (e.g., "っ", "ゃ", "ゅ", "ょ") and diacritic marks (dakuten, handakuten) cannot be input into a
TextField
. Additionally, toggle input (e.g., pressing 'あ' multiple times to switch to 'い', 'う', etc.) does not work as expected.Steps to Reproduce or Code Sample to Reproduce:
TextField
.For a detailed demonstration of the issue, please refer to the attached reproduction video.
Actual Results:
Expected Results:
Reproduction Rate:
100%
This issue occurs every time under the described conditions.
Environment:
TextField
is used.Additional Information:
According to our investigation, POBox is pre-installed on Xperia devices up to the Xperia 1, released in 2019 (https://www.sony.jp/xperia/xperia/xperia1/?srsltid=AfmBOoox1BTdp0e7TprBv0hcGsft9wxrpNf_-KepPYoCqf6QgXX6axE1 ). As a result, this issue could affect a significant number of Android users in Japan.
While we suspect the issue may be related to the combination of Xperia devices and POBox, we would greatly appreciate your investigation into a potential solution or workaround within Jetpack Compose.
Workaround Attempted:
As a workaround for this issue, we attempted to directly use
EditText
withinAndroidView
by utilizingViewBinding
in the Compose environment. However, we encountered another issue in our project that prevented us from using this workaround effectively.It would be greatly appreciated if you could also prioritize investigating and addressing this issue. Here is the link to the related issue:
https://partnerissuetracker.corp.google.com/issues/369354336#comment4
Sample App to Reproduce:
https://github.com/yurihondo/screentransitionsample
You can reproduce the issue using this app:
Please especially check the implementation at the following location:
https://github.com/yurihondo/screentransitionsample/blob/c71e4d6f41c76cdeb8a359e3cc6938a5250ac5da/feature/applepie/src/main/java/com/yurihondo/screentransitionsample/applepie/EditRoute.kt#L76