IssueTracker

class FixDrawerLayout @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
) : DrawerLayout(context, attrs) {

    fun registerToFragmentLifecycle(fragment: Fragment) {
        fragment.viewLifecycleOwner.launchOnLifecycleDestroy {
            super.onDetachedFromWindow()
        }
    }
}

With markdown the same:

I have a project on SingleActivity. And in manifest android:enableOnBackInvokedCallback="true". I have a Root Fragment with a toolbar to which I attach a DrawerLayout.

<!-- XML Root Fragment -->
<androidx.drawerlayout.widget.DrawerLayout>

    <androidx.coordinatorlayout.widget.CoordinatorLayout>
        <com.google.android.material.appbar.AppBarLayout>
            <com.google.android.material.appbar.MaterialToolbar />
        </com.google.android.material.appbar.AppBarLayout>
        <androidx.fragment.app.FragmentContainerView />
    </androidx.coordinatorlayout.widget.CoordinatorLayout>

    <androidx.core.widget.NestedScrollView
        android:layout_gravity="start">

</androidx.drawerlayout.widget.DrawerLayout>

On button click in DrawerLayout I change RootFragment and lose all View in this Xml after onDestroyView. I don't call close() or closeDrawer() because I need the old state when I return to this fragment. But!

The DrawerLayout calls onDetachedFromWindow() which calls updateBackInvokedCallbackState() where ViewCompat.isAttachedToWindow(this) returns true and all the following condition is also true.

boolean shouldBeRegistered = visibleDrawer != null
    && currentDispatcher != null
    && getDrawerLockMode(visibleDrawer) == LOCK_MODE_UNLOCKED
    && ViewCompat.isAttachedToWindow(this);

As a consequence, the following code cannot be executed:

        } else if (!shouldBeRegistered && mBackInvokedDispatcher != null) {
            Api33Impl.tryUnregisterOnBackInvokedCallback(
                    mBackInvokedDispatcher, mBackInvokedCallback);
            mBackInvokedDispatcher = null;
        }

Where mBackInvokedDispatcher != null is true, and shouldBeRegistered is true (but !shouldBeRegistered is false).

Consequently, my mechanical back button or slide (back gesture) is blocked and not called on a new Root fragment when the DrawerLayout is Destroyed.

<!-- new Root fragment -->
<androidx.coordinatorlayout.widget.CoordinatorLayout>
    <com.google.android.material.appbar.AppBarLayout>
        <com.google.android.material.appbar.MaterialToolbar />
    </com.google.android.material.appbar.AppBarLayout>

    <androidx.fragment.app.FragmentContainerView />

</androidx.coordinatorlayout.widget.CoordinatorLayout>

There may be a workaround, but that's not all. The fact is that LeakCanary reacts to this error, which claims that after registerOnBackInvokedCallback and not called tryUnregisterOnBackInvokedCallback, a memory leak occurs.

fast fix: android:enableOnBackInvokedCallback="false" or downgrade DrawerLayout to 1.1.1 or https://issuetracker.google.com/issues/296986132#comment2

after the drawer layout closed

According to my requirements, it should not close, since there is a screen animation where you can see that it is open. So the hot fix only helps through custom view.

fun registerToFragmentLifecycle(fragment: Fragment) {
    fragment.viewLifecycleOwner.launchOnLifecycleDestroy {
        super.onDetachedFromWindow()
    }
}

Here's my sample app btw - https://github.com/ZOlbrys/BackNavigationTestApp/tree/master

Again, I'm not sure if our issues are exactly the same, but I get "stuck" not being able to swipe back between fragments after navigating to a fragment starting from a menu item being selected in a Drawer Layout - so it sounds similar...

launchOnLifecycleDestroy ->

fun(block: suspend CoroutineScope.(Lifecycle.Event) -> Unit) {
    coroutineScope.launch {
        val observer = LifecycleEventObserver { _, event -> launch { if (Event.ON_DESTROY == event) block(event) } }
    
        addObserver(observer)
        
        try {
            awaitCancellation()
        } catch (_: CancellationException) {
            removeObserver(observer)
        }
    }
}

I found that if the drawer layout is part of a fragment, which is in turn replaced with another fragment as part of a navigation action, the bug occurs (back actions are consumed and not forwarded to the app as expected).

However, if you place the drawer layout as part of the parent activity, no bug occurs when you navigate from the drawer layout to another fragment/back/etc.

I assume that's because the drawer layout, when part of the activity, never goes destroyed/removed from the view, so it does not encounter the bug in question.

This is beginning to look like a separate issue related to navigation logic with drawer layouts in fragments/non-activity lifecycles.

I agree with you completely.