Fixed
Status Update
Comments
su...@google.com <su...@google.com>
su...@google.com <su...@google.com> #2
Please include a sample project that reproduces your issue.
kj...@gmail.com <kj...@gmail.com> #3
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?
lo...@gmail.com <lo...@gmail.com> #4
Hello, have you checked sample project? I hope it will help find the issue.
be...@airbnb.com <be...@airbnb.com> #5
fe...@gmail.com <fe...@gmail.com> #6
Hello, any update please?
su...@google.com <su...@google.com>
il...@google.com <il...@google.com> #7
Hello
I raised similar issue with this ticket
This makes the SearchView unusable/broken when fragments are changed (i.e base on searchView input query)
What can we do to fix this problem? What is the progress of work on solving this problem?
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #8
@7 Check @5 for a workaround.
jb...@google.com <jb...@google.com> #9
Hi, i am also facing this issue after we dismiss a DialogFragment, the callback comes in the onPrepareOptionsMenu(), which is causing the issues for me.
Any idea on when it will be fixed?
Any idea on when it will be fixed?
Description
Since enabling android 13's
enableOnBackInvokedCallback
setting, our app has been experiencing a number of sporadic crashes originating in android only code.Our app only uses OnBackPressedCallback, and registers using LifecycleOwners. (We do not change OnBackInvokedDispatcher).
I have not been able to create a reliable reproduction, however, have a hypothesis from reading through the source code.
WindowOnBackInvokedDispatcher
is invoking anOnBackPressedDispatcher
with no enabled OnBackPressedCallbacks. The crash itself seems to imply the FragmentManager has been destroyed.OnBackPressedDispatcher
, there isnavigateBack
does not perform apopBackStackImmediate
which is different from the OnBackPressedDispatchersfallback
which ultimately invokespopBackStackImmediate
WindowOnBackInvokedDispatcher
uses asetTopOnBackInvokedCallback
.WindowOnBackInvokedDispatcher
, if there is a back-press enqueued while there is another message ahead of it which will causeWindowOnBackInvokedDispatcher
to update it's topCallback, it can run on a stale callback.This race condition ultimately means that
Activity.onBackPressed
is invoked instead ofActivity.navigateBack
, exposing the app to the crash in fragment manager'spopBackStackImmediate
.This is just speculation, but from our crash breadcrumbs it does seem that this crash is also proceeded by the destroy event of an activity 5-100ms prior.
It would be much appreciated to have the perspective of someone more familiar with the platform code. We are seeing a steady increase in this crash as more users adopt android 13.