Fixed
Status Update
Comments
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-main
commit b9b1326edfe38588a9882e1ee624798966c5686a
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Oct 06 16:49:53 2021
Clear focus on Fragments animating out
Since moving to the new state manager, fragment now explicitly handle
focus where in the old world they could ignore it altogether. This
change has the side effect that other things affected by focus (i.e.
soft keyboard input) are affect as well. In particular when we
requestFocus we update the input request, but since we never clear it
users have to manually remove the input.
When we are animating a fragment view out, since we will no longer be
using the exiting view, let clear the focus of before we remove it from
the fragment.
RelNote: "The keyboard will now close automatically when going from
a fragment with an open keyboard to a fragment with a recycler view."
Test: tested in sample app from bug
Bug: 196852211
Change-Id: I8b842dd9a421cfbc9189014b802f5e4b6b9c2a47
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
https://android-review.googlesource.com/1847143
Branch: androidx-main
commit b9b1326edfe38588a9882e1ee624798966c5686a
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Oct 06 16:49:53 2021
Clear focus on Fragments animating out
Since moving to the new state manager, fragment now explicitly handle
focus where in the old world they could ignore it altogether. This
change has the side effect that other things affected by focus (i.e.
soft keyboard input) are affect as well. In particular when we
requestFocus we update the input request, but since we never clear it
users have to manually remove the input.
When we are animating a fragment view out, since we will no longer be
using the exiting view, let clear the focus of before we remove it from
the fragment.
RelNote: "The keyboard will now close automatically when going from
a fragment with an open keyboard to a fragment with a recycler view."
Test: tested in sample app from bug
Bug: 196852211
Change-Id: I8b842dd9a421cfbc9189014b802f5e4b6b9c2a47
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
jb...@google.com <jb...@google.com> #3
This has been fixed internally and will be available in the Fragment 1.4.0-beta01
release.
pa...@gmail.com <pa...@gmail.com> #4
The issue still persist in API version 27 and below in Fragment 1.4.0
Description
Component used: Fragment
Version used: 1.3.0
Devices/Android versions reproduced on: Android Studio Emulator with Android 11
I found a bug that requires the use of the Fragment library from 1.3.0 and up (I still reproduce the bug in the version 1.4.0-alpha06), custom animations in FragmentTransactions and a RecyclerView (of androidx.recyclerview:recyclerview:1.2.1).
If a fragment over which the soft keyboard is shown (because an EditText is focused for example), is replaced with a new fragment that shows a RecyclerView, and custom animations are set in the FragmentTransaction, then the soft keyboard is not automatically dismissed and is displayed over the second fragment. If the second fragment does not show a RecyclerView, or custom animations are not set in the FragmentTransaction, then the soft keyboard is automatically dismissed.
It is a regression since the soft keyboard was dismissed correctly when using a version of the Fragment library below 1.3.0.
I suspect that the issue comes from the new fragment state manager since I could not reproduce the issue when disabling it with the method:
I attached a screen recording of the issue captured on a Samsung Galaxy Tab s7, and a sample project.