Options menu flicker when switching between fragments and using MenuProvider interface [243679672]

Bug

Status Update

No update yet.

Description

to...@gmail.com

created issue #1

Aug 24, 2022 06:29PM

I am trying to migrate from the deprecated setHasOptionsMenu()/onCreateOptionsMenu() methods to the new addMenuProvider()/onCreateMenu() methods in order to show an options menu from a fragment. Using the new API, I get an ugly delay/flicker of the icons in the action bar when navigating between two fragments that both implement MenuProvider.

I assume this is caused by asynchronous lifecycle callbacks: the new fragment's menu is probably inflated and added just before the old fragment's Lifecycle.Event.ON_DESTROY event triggers the removal of the old menu items, causing a brief moment when both menus are active simultaneously. However, I can't figure out how to avoid this behavior. I have tried calling both removeMenuProvider() and invalidateOptionsMenu() from onDestroyView() in each fragment with no success. I also tried moving addMenuProvider() to onViewCreated() instead of onCreateView(). The issue does not occur with the old setHasOptionsMenu() API.

Minimal reconstruction:

Open Android Studio, create a new project, and select the "Bottom Navigation Activity" template.
Create two menu resource files, each containing at least one menu item with an icon and app:showAsAction="always".
In two of the fragments shown by the bottom navigation controller, call the following from within onCreateView():

requireActivity().addMenuProvider(object: MenuProvider {
    override fun onCreateMenu(menu: Menu, menuInflater: MenuInflater) {
        menuInflater.inflate(/* one of the menus from step 2 */, menu)
    }

    override fun onMenuItemSelected(menuItem: MenuItem): Boolean {
        return false
    }
}, viewLifecycleOwner)

Run the app and switch between these fragments using the bottom navigation bar. You should see something like this: example gif.

Comments

jb...@google.com <jb...@google.com> #2Aug 24, 2022 09:00PM

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 fitSystemWindows from views if you're handling insets manually
Override dispatchApplyWindowInsets in the view groups above where you have fitSystemWindows defined, 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

to...@gmail.com <to...@gmail.com> #3Aug 24, 2022 09:16PM

Using composable version 1.2.1, I could fix it using:

override fun onCreate(bundle: Bundle?) {
        WindowCompat.setDecorFitsSystemWindows(window, false)
        super.onCreate(bundle)
        if (Build.VERSION.SDK_INT > Build.VERSION_CODES.Q){
            window.setFlags(WindowManager.LayoutParams.FLAG_LAYOUT_NO_LIMITS, WindowManager.LayoutParams.FLAG_LAYOUT_NO_LIMITS)
        }
}

Then statusBarsPadding works as expected on Api 29

il...@google.com <il...@google.com> #4Aug 24, 2022 11:08PM

Is there a possibility that this bug is somehow impacting View based onApplyWindowInsetsListener s? I am seeing an issue when navigating from a compose based (non-edge-to-edge) fragment to a view based edge-to-edge fragment where the onApplyWindowInsetsListeners are not being called. This is fixed by simply calling requestApplyInsets() in an onLayoutChangedListener, but I am trying to get down to the root of the problem. Unfortunately I am unable to post any code, but have been digging for a while in to the windowInsets source code and can't find anything. This only happens when the proceeding fragment is Compose based.

to...@gmail.com <to...@gmail.com> #5Aug 25, 2022 01:23AM

Ahh I see what you mean now, thank you both! Setting the state parameter to RESUMED in addMenuProvider prevents the overlap as desired. It would be good to have a note about this in the documentation. It makes perfect sense now, but may not be immediately obvious to those looking to transition from the old API.

On a very minor note, there is still a delay as compared to setHasOptionsMenu. In the old API, the menu icon is replaced smoothly and instantaneously, but with the new API there is a brief moment where neither icon is visible, causing a slight visual "flash". I assume that's unavoidable at the moment given the lifecycle state transitions, but it would be nice to recreate the old behavior.

ra...@gmail.com <ra...@gmail.com> #6May 26, 2023 03:33PM

Comment has been deleted.

Message last modified on Jun 2, 2023 11:03AM

ra...@gmail.com <ra...@gmail.com> #7Jun 2, 2023 11:08AM

In my case , when I click on the menu icon to show a dialog, the icon hides & coming back when screen resume, I can't use STARTED as it would overlap with other fragments menu options, Is there any workaround to fix hiding the icon, i'm aware that it is adding/removing provider based on lifecycle, but is there a workaround in this case?

   view.requireActivity().addMenuProvider(
        provider,
        view.requireViewLifecycleOwner(),
        Lifecycle.State.RESUMED
    )

Issue 243679672