Status Update
No update yet.
Comments
il...@google.com
ap...@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
When using the new fragment state manager, all of the operations within a single FragmentTransaction are always optimized. This means that using complementary operations such as add/remove or attach/detach on the same fragment instance, in the same transaction will cancel each other out and end up not changing the state of the fragment.
For FragmentTransactions in the old world that were using
reorderingAllowed(true)this will not change since that optimizes operations both within and between transactions. For all other transactions, if you would like to match the old world behavior you need to explicitly separate the complementary operations into two separate fragment transactions. As long as you use the samecommit()method you were using before, the behavior should be identical.We should figure out a way to address this in the library. There should be a lint rule that warns against using complementary operations, in the same transaction, on the same fragment. It is less likely, but possible that we may also need to add some logic that detects these cases and runs them independently.