Status Update
No update yet.
Comments
il...@google.com
I'm marking this as "won't fix" as there's nothing Compose here can do, as this is a platform quirk that has been adjusted to be more predictable in recent API versions.
The crux of the issue here is the fitSystemWindows in the extra View, like you mentioned, and a platform change in API 30.
Prior to API 30, window insets were dispatched through the view hierarchy in a non-intuitive way: Rather than being a full breadth-first traversal, they would be dispatched in preorder. If the insets were consumed at any point (like if you use fitSystemWindows), then the preorder would prevent insets from being dispatched to the rest of the view hierarchy. This is very unintuitive: It meant that sibling views (or views deeper in the tree) could stop later views from receiving the dispatch of insets.
In API 30, this behavior was changed to be more intuitive: Now, insets are dispatched in a top-down manner, so they can't be consumed in this weird, cross-tree way.
There's a couple solutions here:
- Avoid
fitSystemWindowsfrom views if you're handling insets manually - Override
dispatchApplyWindowInsetsin the view groups above where you havefitSystemWindowsdefined, and manually perform the new, non-broken dispatching behavior. You can see a comparison of the two methods here:https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/view/ViewGroup.java;l=7341-7371;drc=6411c81462e3594c38a1be5d7c27d67294139ab8
Description
I am experiencing an issue with androidx.fragment:fragment-ktx versions 1.7.0-alpha01 and above. When navigating back from a fragment using a regular back gesture (edge swipe or back button), the toolbar overflow menu updates to reflect the next fragment in the stack before the back navigation completes. The premature menu update happens while the current fragment is still visible on the screen.
This issue does not occur in version 1.6.2 of the androidx.fragment library and seems to be introduced starting from version 1.7.0-alpha01.
Steps to Reproduce:
Use androidx.fragment:fragment-ktx:1.7.0-alpha01 or later. Navigate between two fragments using the Android Navigation Component with nav graph. Set up the toolbar with an overflow menu specific to each fragment. Perform a back navigation gesture (swipe or back button) from the second fragment to return to the first fragment. Observe that the toolbar overflow menu updates to reflect the first fragment before the back navigation completes, even though the second fragment is still visible.
Expected Behavior:
The toolbar overflow menu should not update until the back navigation is complete and the previous fragment is fully removed from view.
Observed Behavior:
The toolbar overflow menu updates prematurely while the second fragment is still partially visible during the back navigation gesture.
Environment:
Fragment Library Version: 1.7.0-alpha01 to 1.8.2 Navigation Component: androidx.navigation:navigation-fragment-ktx:2.5.3 (or latest version used) Device: Pixel 6, Pixel 8 Pro and emulators Android Version: Android 14 and 15 Target SDK: My app target SDK is 34
Additional Context:
This issue did not occur in androidx.fragment:fragment-ktx:1.6.2 and appears to have been introduced in version 1.7.0-alpha01 or later. It may be related to changes in fragment lifecycle management and transitions introduced in these versions.
Additionally, I can cause my app to crash by initiating a back gesture from one Fragment to the previous one, holding the gesture, and then canceling it. After that, when I navigate to a different screen, the app crashes with the following error message:
FATAL EXCEPTION: main java.lang.IllegalArgumentException: saveBackStack("e11eacf2-c38e-4293-8b79-f299d7de163c") must be self contained and not reference fragments from non-saved FragmentTransactions. Found reference to fragment HomeFragment{e2dd527} (05924717-51f0-4893-831b-81c350b0e466 id=0x7f0a027b tag=9b9fb6da-2829-47f9-b6f0-b12ae27b7055) in BackStackEntry{b476673 #8 e11eacf2-c38e-4293-8b79-f299d7de163c} that were previously added to the FragmentManager through a separate FragmentTransaction.Please find attached video recordings for both scenarios.