Fixed
Status Update
No update yet.
Comments
il...@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?
il...@google.com
Hello, have you checked sample project? I hope it will help find the issue.
zv...@gmail.com
zv...@gmail.com
Hello, any update please?
il...@google.com
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?
[Deleted User] <[Deleted User]>
@7 Check @5 for a workaround.
jb...@google.com
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?
cr...@gmail.com
Hello, any estimate please?
Description
Version used: 1.0.0-rc02
When using a Fragment such as:
<fragment>
...
<argument
android:name="myArg"
app:argType="string"
app:nullable="true"
android:defaultValue="@null"/>
</fragment>
The defaultValue="@null" causes that attribute to be dropped by the NavInflater (due to now XmlPullParser works), meaning the resulting arguments Bundle can be null as there is no way to distinguish between no default value being set and a null default value being set.
Unfortunately, even in the case where no arguments are required, Safe Args' fromBundle() and, by extension, the by navArgs(), require a non-null Bundle.
fromBundle() should only throw on a null Bundle if there are required values.