Fixed
Status Update
No update yet.
Comments
da...@google.com
Please include a sample project that reproduces your issue.
il...@google.com
ap...@google.com
Here is the sample project.
Steps to reproduce:
1. Press on "Search" icon;
2. Write something;
3. Search this text, keyboard will be dismissed;
4. Tap on "Dialog" button;
5. Dissmiss dialog;
With the new 1.5.0 fragment library version text will be cleared in the search box after dismissing dialog.
In the version 1.4.1 and lower text in the search is not clearing and this is correct behaviour.
Please suggest some workarounds or how to fix this issue?
Steps to reproduce:
1. Press on "Search" icon;
2. Write something;
3. Search this text, keyboard will be dismissed;
4. Tap on "Dialog" button;
5. Dissmiss dialog;
With the new 1.5.0 fragment library version text will be cleared in the search box after dismissing dialog.
In the version 1.4.1 and lower text in the search is not clearing and this is correct behaviour.
Please suggest some workarounds or how to fix this issue?
jb...@google.com
Hello, have you checked sample project? I hope it will help find the issue.
Description
Version used: fragment-ktx:1.3.0-beta01
This bug is part of the problem of
Steps to reproduce
- Fragment1 replaced with fragment2, then press BACK as soon as I see the fragment2 is showing.
- Upon returning, fragment1 calls AnimationInfo.mFocusedView.requestFocus(). However the view being called requestFocus() belongs to the old view tree, it's not belonging to the new view tree that is created during returning.
The bug is hard to reproduce. It's around 1/50 for me using project at
Attached a screenshot showing "detached state" of the view.
The bug is probably not critical because calling requestFocus() on a detached view should be no-op. But it may cause problem if the app added a onFocusChange listener and perform some logic in the fragment (as illustrated in leanback crash