Fixed
Status Update
No update yet.
Comments
al...@google.com
[Deleted User] <[Deleted User]>
Please include a sample project that reproduces your issue.
ky...@gmail.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?
al...@google.com
Hello, have you checked sample project? I hope it will help find the issue.
al...@google.com
rg...@google.com
da...@gmail.com
Hello, any update please?
ho...@eure.jp
Comment has been deleted.
rg...@google.com
@7 Check @5 for a workaround.
vr...@deezer.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?
br...@monzo.com
Hello, any estimate please?
rg...@google.com
ti...@google.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.
en...@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
ti...@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.
ti...@google.com
This has been fixed internally and will be available in the Fragment 1.6.0-alpha07 release.
en...@gmail.com
@15 I've noticed I can avoid using the fragment dependency and still work fine with fragments. How come?
It's part of the material dependency, perhaps?
It's part of the material dependency, perhaps?
ti...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.fragment:fragment:1.6.0-alpha07
ap...@google.com
@17 What if I don't use this dependency (probably imported automatically by material dependency) ? Use it, still?
jb...@google.com
@17 I wanted to try what you wrote on the sample I've provided (after I remove my workaround), and for some reason it doesn't let me.
It says "Duplicate class found".
The IDE doesn't provide any useful explanation of what is the class that is duplicated and what to do about it.
Please help.
It says "Duplicate class found".
The IDE doesn't provide any useful explanation of what is the class that is duplicated and what to do about it.
Please help.
ti...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.fragment:fragment:1.5.6
de...@gmail.com
@20 Not 1.6.0-alpha07 ?
gr...@gmail.com
@21 androidx.fragment:fragment:1.5.6 is a STABLE release. It has the fix we need. The androidx.fragment:fragment:1.6.0-alpha07 is an alpha as it says. 1.6 is "work in progress". 1.6.0 is still not a stable release. Use "alpha" only for testing
ch...@gmail.com
@22 So it's fixed on both. OK
ti...@google.com
Hi Jeremy,
Do you have any update about the new release?
jb...@google.com
Build cut is this Wednesday and it will be released next week as part of Fragment 1.8.6.
de...@gmail.com
an...@dnb.no
Any update on the new release?
Description
According to docs
WindowInsetsCompat.CONSUMEDused inViewCompat.setOnApplyWindowInsetsListenerlambda should affect only View's direct children. This is working as expected on API >= 30, but on lower API's it affects whole View hierarchy making all other Views (even indirect children) ignore Insets.This behaviour is reproduced here:https://github.com/ai-corpo/InsetsTest . On API 30
NestedScrollViewrespects bottom Inset even if topAppBarreturnedWindowInsetsCompat.CONSUMED, but on lower API's same code makesNestedScrollViewignore Insets.