Sliding two-pane scene unexpectedly shows blank white pane on pop transition

[marcardar]

Describe the bug

This is a follow-up to the closed recipe-request #248

It was recommended to use these transition specs to achieve the sliding transition:

transitionSpec = {
    slideInHorizontally { it / 2 } togetherWith slideOutHorizontally { -it / 2 }
},
popTransitionSpec = {
    slideInHorizontally { -it / 2 } togetherWith slideOutHorizontally { it / 2 }
},
predictivePopTransitionSpec = {
    slideInHorizontally { -it / 2 } togetherWith slideOutHorizontally { it / 2 }
},

While this mostly works, there is a problem when performing a quick back gesture: instead of the right pane (for the exiting entry) sliding out to the right, it just disappears instantly leaving a blank white space. There is no such problem when using a full predictive back gesture, nor when using the 3-button back navigation button.

So, curiously, it only happens when flicking the back gesture as shown in the video.

Steps to reproduce

First, ensure that the above specs are in place in TwoPaneActivity.kt

1. Enable gesture navigation on device
2. Launch nav3-recipes and go to Two Pane recipe
3. Ensure device in landscape
4. Click on View first product / view the next product / view the next product so that the right pane is Product 2
5. Do a flick of the back gesture from left edge of screen

Expected behavior

Right pane (Product 2) should gradually slide out to the right, just like it does when performing normal back or slow predictive back.

Actual behavior

The right pane goes white instantly before the left pane gradually slides over it

Screenshots

Screen_recording_20260317_101603.mp4

Additional context

Curiously, there are no issues when going back from Product 1. It only happens when the left pane is a Product pane.

There are other issues with the transitions in single-pane (portrait orientation) scene because it / 2 (which should only apply to a balance two column scene) is applied at NavDisplay level rather than scene level.

[CODEVIBE-dev]

I am experiencing the exact same issue in my own project using Navigation3, but under slightly different conditions.

Unlike the original report, I am not using a two-pane scene; my app consists of standard, single screens.

Interestingly, I've noticed that the issue's occurrence depends directly on the backstack depth:

• Works perfectly: Popping from Screen 2 back to Screen 1 (the root of the backstack) via the back gesture. The transition is smooth.
• Issue occurs: Popping back from any screen deeper in the backstack to the previous one (e.g., Screen 3 -> Screen 2, or Screen 5 -> Screen 4). In these cases, the glitch always happens on the pop transition.

I wanted to share this context in case the single-pane setup or the backstack depth helps pinpoint the root cause.

[bsagmoe]

I'm not currently able to reproduce this following the steps you shared. Could you share the library versions you're using?

Screen_recording_20260420_160729.mp4

There are other issues with the transitions in single-pane (portrait orientation) scene because it / 2 (which should only apply to a balance two column scene) is applied at NavDisplay level rather than scene level.

It looks like this was discussed in the original thread as well, but as a concrete example, you can set the transition spec metadata in the Scene implementation itself:

data class TwoPaneScene<T : Any>(...) : Scene<T> {

    ...

    override val metadata = metadata {
        put(NavDisplay.TransitionKey) {
            slideInHorizontally { it / 2 } togetherWith slideOutHorizontally { -it / 2 }
        }
        put(NavDisplay.PopTransitionKey) {
            slideInHorizontally { -it / 2 } togetherWith slideOutHorizontally { it / 2 }
        }
        put(NavDisplay.PredictivePopTransitionKey) {
            slideInHorizontally { -it / 2 } togetherWith slideOutHorizontally { it / 2 }
        }
    }

    ...
}

[CODEVIBE-dev]

Thanks @bsagmoe — moving the transition spec into TwoPaneScene.metadata makes sense architecturally, especially to avoid the / 2 offset applying in portrait/single-pane mode.

That said, I don't think it addresses the issue I described. My case is a single-pane app with no TwoPaneScene involved. The glitch is backstack-depth-dependent:

• ✅ Screen 2 → Screen 1 (root): transition works correctly
• ❌ Screen 3 → Screen 2, Screen 4 → Screen 3, etc.: pop transition glitches

Library version: androidx.navigation3:navigation3-runtime:1.0.1 + androidx.lifecycle:lifecycle-viewmodel-navigation3:2.10.0

Animation setup:
We're using a custom per-destination transition system. Each NavDisplay entry receives its transition via metadata = key.getTransitionMetadata(), where the destination itself declares its transitionType. For the default SlideHorizontal type:

  private fun getSlideHorizontalMetadata(): Map<String, Any> = NavDisplay.transitionSpec {
      slideInFromRight() togetherWith slideOutToLeft()   // slideOutToLeft offset: { -it / 5 }
  } + NavDisplay.popTransitionSpec {
      slideInFromLeft() togetherWith slideOutToRight()   // slideInFromLeft offset: { -it / 5 }
  } + NavDisplay.predictivePopTransitionSpec { swipeEdge ->
      when (swipeEdge) {
          EDGE_LEFT -> slideInFromLeft { -it / 3 } togetherWith slideOutToRight { it }
          EDGE_RIGHT -> slideInFromRight { it / 3 } togetherWith slideOutToLeft { -it }
          else -> slideInFromLeft() togetherWith slideOutToRight()
      }
  }

There's no global default transition at the NavDisplay level — each entry carries its own. I wonder if the bug is related to how metadata is resolved for entries already sitting in the back stack (Screen 2 when popping from Screen 3), vs. a freshly pushed entry 🤔

[LakshmanSagar]

I can confirm I'm seeing the same behavior in my app as @CODEVIBE-dev mentioned.

My setup is also a standard single-pane Navigation3 app (no two-pane scenes).

Similar to your observations, the issue occurs during pop transitions on deeper back stack entries rather than when popping directly back to the root destination.

In my case, the navigation state itself is correct after the pop, but the rendered destination occasionally remains translated off-screen after rapid back presses. Depending on the slide offset, this appears either as a partial white strip or a completely white screen.

From my debugging, this appears to be a rendering/transition issue rather than an incorrect navigation state.

[LakshmanSagar]

I have some additional findings that may help narrow this down.

I first tried replacing my slide transitions with simple fade transitions to see if the issue was caused by the horizontal animation itself. The issue still occurred, so changing the transition type alone did not resolve it.

I then compared my implementation against the official nav3-recipes multiple back stacks sample.

My NavDisplay is configured as follows:

NavDisplay(
    entries = decoratedEntries,
    onBack = { navigationManager.handleBackPress() },
    transitionSpec = standardSlideIn,
    popTransitionSpec = standardSlidePop,
    predictivePopTransitionSpec = { _ -> standardSlidePop() }
)

One notable difference I found was how the decorated entries passed to NavDisplay are selected.

My original implementation returned all retained top-level routes:

private fun getTopLevelRoutesInUse(): List<AureliaKey> {
    if (currentRootKey is LoginKey ||
        currentRootKey is OnboardingKey ||
        currentRootKey is AddUserKey
    ) {
        return listOf(currentRootKey)
    }

    val baseTabs = activeBottomTabs.filter { it != currentRootKey }
    return baseTabs + currentRootKey
}

I then changed it to match the approach used in the official nav3-recipes multiple back stacks sample:

private fun getTopLevelRoutesInUse(): List<AureliaKey> {
    if (currentRootKey is LoginKey ||
        currentRootKey is OnboardingKey ||
        currentRootKey is AddUserKey
    ) {
        return listOf(currentRootKey)
    }

    return if (currentRootKey == HomeKey) {
        listOf(HomeKey)
    } else {
        listOf(HomeKey, currentRootKey)
    }
}

I have not been able to reproduce the issue after making this change.

Other than my earlier transition experiments, this was the only behavioral change. This seems to indicate that the set of decorated entries participating in NavDisplay may be related to the issue rather than the transition animation itself.

Is NavDisplay expected to receive decorated entries for all retained top-level back stacks, or only for the currently active top-level routes as demonstrated in the official nav3-recipes sample?

If it would be helpful, I'm happy to share the relevant parts of my AppNavigationManager and NavDisplay implementation for comparison.

[LakshmanSagar]

Update

After further investigation, I can no longer reproduce this issue in my application.

The issue was resolved after making both of the following changes.

1. Aligning getTopLevelRoutesInUse() with the official Navigation3 multi-stack pattern

Previous implementation (all retained bottom tabs):

private fun getTopLevelRoutesInUse(): List<AureliaKey> {
    if (currentRootKey is LoginKey ||
        currentRootKey is OnboardingKey ||
        currentRootKey is AddUserKey
    ) {
        return listOf(currentRootKey)
    }

    val baseTabs = activeBottomTabs.filter { it != currentRootKey }
    return baseTabs + currentRootKey
}

Current implementation (matching the official nav3-recipes sample):

private fun getTopLevelRoutesInUse(): List<AureliaKey> {
    if (currentRootKey is LoginKey ||
        currentRootKey is OnboardingKey ||
        currentRootKey is AddUserKey
    ) {
        return listOf(currentRootKey)
    }

    return if (currentRootKey == HomeKey) {
        listOf(HomeKey)
    } else {
        listOf(HomeKey, currentRootKey)
    }
}

This limits NavDisplay to the primary (Home) stack and the currently active top-level stack instead of supplying all retained tab stacks simultaneously.

---

2. Removing the application-level back press debounce

Previous implementation:

private var lastNavTime = 0L

fun handleBackPress(): Boolean {
    val now = System.currentTimeMillis()
    if (now - lastNavTime < 400L) {
        return true
    }
    lastNavTime = now

    if (activeBackStack.size > 1) {
        activeBackStack.removeAt(activeBackStack.lastIndex)
        return true
    }

    if (currentRootKey != startRoute) {
        currentRootKey = startRoute
        return true
    }

    return false
}

Current implementation:

fun handleBackPress(): Boolean {
    if (activeBackStack.size > 1) {
        activeBackStack.removeAt(activeBackStack.lastIndex)
        return true
    }

    if (currentRootKey != startRoute) {
        currentRootKey = startRoute
        return true
    }

    return false
}

Previously, the debounce consumed some back events (return true) without performing any navigation state change. Removing it ensured that every consumed back event corresponded to an actual navigation state mutation.

Testing observations

Both changes were required during testing:

• Reverting to the previous getTopLevelRoutesInUse() implementation caused the rendering issue to reappear.
• Keeping the previous getTopLevelRoutesInUse() implementation while only removing the debounce was also insufficient to eliminate the issue.

Based on my testing, I currently believe this was caused by my application's interaction with NavDisplay rather than a Navigation3 framework defect.

Since I can no longer reproduce the issue after the changes above, I'll close this report. If I can reproduce it again with a minimal sample following the official Navigation3 multi-stack pattern, I'll reply here with the issue.

I hope this information is helpful.

@CODEVIBE-dev This may be similar to the issue you were seeing, so I wanted to share what ultimately resolved it in my case.