Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fast switching between tab bars causing creating new tab instead of restoring previous one #1285

Open
mkowol-n opened this issue Mar 14, 2024 · 8 comments

Comments

@mkowol-n
Copy link

Hi,
I found a bug related to navigation. I have an application with bottom nav bar. When i navigate between them using :
navigator.resetRoot(HomeNavTab2, saveState = true, restoreState = true)
everything works fine - the state of each tab is being restored. However, when I rapidly switch between the tabs (akin to "spamming"), the expected state restoration does not occur. Instead, a new screen is generated each time."

@ZacSweers
Copy link
Collaborator

Can you link a sample we could reproduce this on? A test would be ideal but even just a sample app that we could manually try. Otherwise there's not much for us to go on here

@mkowol-n
Copy link
Author

mkowol-n commented Mar 14, 2024

@ZacSweers sure, here is the repo:
https://github.com/mkowol-n/SlackNavIssue

@mkowol-n
Copy link
Author

@ZacSweers
Copy link
Collaborator

Is this possibly related to #1312? i.e. debouncing issues

@ZacSweers
Copy link
Collaborator

Closing as fixed in 0.21.0

@diousk
Copy link

diousk commented Jan 14, 2025

Hi @ZacSweers,

I believe issue #1285 is not fully resolved.
While PR #1331 addressed the goTo case, the resetRoot inconsistency still occurs.

Steps to reproduce:

  1. Using the test repo at https://github.com/mkowol-n/SlackNavIssue
  2. Testing with Circuit version 0.25.0
  3. Rapidly switch between tabs (approximately 300ms intervals)

Observed behavior:

  • Colors change unexpectedly during rapid tab switching
  • Colors eventually restore to correct values when switching tabs at a slower pace

This suggests the resetRoot case may need separate handling.

Could you please verify this behavior and consider reopening the issue?

@diousk
Copy link

diousk commented Feb 11, 2025

Hi,

resetRoot() navigation issues: state loss (v0.25.0) and crashes (v0.26.0) during rapid tab switching

(repost from #1930)

Testing has revealed two critical issues with resetRoot() across different Circuit versions:

Circuit v0.25.0:
rememberRetained state is lost during rapid tab switching (~300ms intervals)
Normal navigation retains state correctly
During rapid switching, state resets to initial values

Circuit v0.26.0:
App crashes during rapid tab switching when using resetRoot(saveState = true, restoreState = true)
Error stack trace indicates key registry collision: (though I can't the related circuit code line)

Process: pl.nepapp.slacknavissue, PID: 27021
java.lang.IllegalArgumentException: Key _registry_150d9446-1362-495d-ae1a-67012d6a6140 was used multiple times 
at androidx.compose.runtime.saveable.SaveableStateHolderImpl$SaveableStateProvider$1$1$1.invoke(SaveableStateHolder.kt:90)
at androidx.compose.runtime.saveable.SaveableStateHolderImpl$SaveableStateProvider$1$1$1.invoke(SaveableStateHolder.kt:89)
at androidx.compose.runtime.DisposableEffectImpl.onRemembered(Effects.kt:83)
at androidx.compose.runtime.CompositionImpl$RememberEventDispatcher.dispatchRememberObservers(Composition.kt:1364)
at androidx.compose.runtime.CompositionImpl.applyChangesInLocked(Composition.kt:992)
at androidx.compose.runtime.CompositionImpl.applyLateChanges(Composition.kt:1023)
at androidx.compose.runtime.Recomposer$runRecomposeAndApplyChanges$2$1.invoke(Recomposer.kt:700)
at androidx.compose.runtime.Recomposer$runRecomposeAndApplyChanges$2$1.invoke(Recomposer.kt:585)
at androidx.compose.ui.platform.AndroidUiFrameClock$withFrameNanos$2$callback$1.doFrame(AndroidUiFrameClock.android.kt:41)
at androidx.compose.ui.platform.AndroidUiDispatcher.performFrameDispatch(AndroidUiDispatcher.android.kt:109)
at androidx.compose.ui.platform.AndroidUiDispatcher.access$performFrameDispatch(AndroidUiDispatcher.android.kt:41)
at androidx.compose.ui.platform.AndroidUiDispatcher$dispatchCallback$1.doFrame(AndroidUiDispatcher.android.kt:69)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1561)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1572)
at android.view.Choreographer.doCallbacks(Choreographer.java:1172)
at android.view.Choreographer.doFrame(Choreographer.java:1097)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1546)
at android.os.Handler.handleCallback(Handler.java:995)
at android.os.Handler.dispatchMessage(Handler.java:103)
at android.os.Looper.loopOnce(Looper.java:232)
at android.os.Looper.loop(Looper.java:317)
at android.app.ActivityThread.main(ActivityThread.java:8932)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:591)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:911)
Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [androidx.compose.runtime.PausableMonotonicFrameClock@d1ffd81, androidx.compose.ui.platform.MotionDurationScaleImpl@8a26e26, StandaloneCoroutine{Cancelling}@21caa67, AndroidUiDispatcher@4ca2014]

Steps to reproduce:

  1. Clone test repo: https://github.com/diousk/SlackCircuitNavIssue

  2. Modify Circuit version in build.gradle.kts:
    Test with v0.25.0 to observe state loss
    Test with v0.26.0 to observe crashes

  3. Rapidly switch between tabs (~300ms intervals)
    Note: No instrumental test provided due to complexity of simulating rapid user interactions
    The issue is easily reproducible through manual quick tab switching

@ZacSweers
Copy link
Collaborator

@diousk thanks for pasting the longer trace. The lack of circuit anywhere in that trace makes me skeptical that this is really a circuit issue vs something in compose's runtime. Sure, it may be getting tickled by circuit in some way, but even if we reproduced the above in a test (which I still think you should try to create), there's no indication we can fix the underlying compose runtime issue. Please file an issue on the compose issue tracker. If they investigate and find that it's actually a circuit issue I'm happy to revisit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants