Fixed
Status Update
Comments
ja...@gmail.com <ja...@gmail.com> #2
Please include a sample project that reproduces your issue.
vi...@eitv.com.br <vi...@eitv.com.br> #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?
ti...@candyspace.com <ti...@candyspace.com> #4
Hello, have you checked sample project? I hope it will help find the issue.
aq...@google.com <aq...@google.com> #5
bo...@justin.tv <bo...@justin.tv> #6
Hello, any update please?
aq...@google.com <aq...@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?
ap...@google.com <ap...@google.com> #8
@7 Check @5 for a workaround.
aq...@google.com <aq...@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
Component used: androidx.mediarouter Version used: 1.3.1 Devices/Android versions reproduced on:
When reporting bugs, please always include:
We see the following stack trace in Crashlytics, but we can't reproduce the problem locally.
mr_button_dark_static.xml
refers toic_mr_button_connected_30_dark
,ic_mr_button_disconnected_dark
, andic_mr_button_disabled_dark
.ic_mr_button_disconnected_dark
andic_mr_button_disabled_dark
both havexxhdpi
,xhdpi
,hdpi
, andmdpi
versions, butic_mr_button_connected_30_dark
only hasxxhdpi
andxhdpi
versions, so maybe this is the problem?