Fixed
Status Update
No update yet.
Comments
[Deleted User] <[Deleted User]>
Please include a sample project that reproduces your issue.
il...@google.com
[Deleted User] <[Deleted User]>
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.
[Deleted User] <[Deleted User]>
mi...@gmail.com
Hello, any update please?
[Deleted User] <[Deleted User]>
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
@7 Check @5 for a workaround.
mi...@gmail.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?
il...@google.com
Hello, any estimate please?
mi...@gmail.com
Facing a similar kind of issue when scrolling the fragments using a ViewPager.
https://issuetracker.google.com/issues/267677504
Can you update regarding any progress on this issue.
Can you update regarding any progress on this issue.
da...@gmail.com
Project: platform/frameworks/support
Branch: androidx-main
commit 50f098644adc703ae218b0b7e999629f516a0241
Author: sanura <sanura@google.com>
Date: Thu Mar 02 00:11:35 2023
Add check to only invalidate options menu when contributing menu items
FragmentManager previously appropriately only added
a MenuProvider when the host is a MenuHost **and**
we are at the root fragment that is providing the
menu items. This behavior should be mirrored when
removing a MenuProvider as well, so that only
components that directly contribute menu items will
invalidate the options menu.
Bug: 244336571
Test: all tests pass
Change-Id: I9404ee9fcc9ce6b80d70a93bea720fe4ccf583a0
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentContainerInflatedFragmentTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/OptionsMenuFragmentTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/test/FragmentTestActivity.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentActivity.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
https://android-review.googlesource.com/2465169
Branch: androidx-main
commit 50f098644adc703ae218b0b7e999629f516a0241
Author: sanura <sanura@google.com>
Date: Thu Mar 02 00:11:35 2023
Add check to only invalidate options menu when contributing menu items
FragmentManager previously appropriately only added
a MenuProvider when the host is a MenuHost **and**
we are at the root fragment that is providing the
menu items. This behavior should be mirrored when
removing a MenuProvider as well, so that only
components that directly contribute menu items will
invalidate the options menu.
Bug: 244336571
Test: all tests pass
Change-Id: I9404ee9fcc9ce6b80d70a93bea720fe4ccf583a0
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentContainerInflatedFragmentTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/OptionsMenuFragmentTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/test/FragmentTestActivity.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentActivity.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
il...@google.com
@13 Fixed when? On which version of which dependency?
Please show what to write on gradle file.
Please show what to write on gradle file.
Description
This approach only seem to work on actions originating from the graph's start destination, and fails on actions between any other destinations. I created a sample project which reproduces the issue:
Here is the project's README detailing the issue:
# Bug in Android Navigation Component (alpha06)
(Note: I have only verified this in alpha06, I don't know if it exists in
previous versions)
## The problem
Basically the problem is that the NavOption "clearTask" was removed in
alpha02, and the recommended substitute was to use app:popUpTo pointing to
the root of the graph/the graph ID, together with app:popUpToInclusive="true".
However, this method does not work. It only seems to work for actions
going from the graph's start destination. If we have the following graph:
x y
A ---> B ---> C
Where A, B, and C are fragments, A is the start destination of the grapg,
and x, y are actions going from A to B and B to C respectively. Let's say
the graph's ID is "@+id/graph"
Then, if both actions x and y have
app:popUpTo="@+id/graph"
app:popUpToInclusive="true"
Then when navigating from A to B through x, and then hitting the back button
will exit the app (as expected). But if navigating from A to B to C through
x and y, and then hitting the back button we will navigate back to B — this
is not what was expected. The expected behavior with this graph is to always
exit the app when clicking the back button
## Environment
This was verified using:
Android Studio 3.2 RC 3
Build #AI-181.5540.7.32.4987877, built on August 31, 2018
JRE: 1.8.0_152-release-1136-b06 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.13.6