Not able to navigate from Dialog to Fragment [134089818]

Fixed

Bug

Status Update

No update yet.

Description

mu...@gmail.com

created issue #1

May 31, 2019 04:03AM

Component used: Navigation
Version used: 2.1.0-alpha04
Devices/Android versions reproduced on: S10

I am trying to navigation from DialogFragment to Fragment in Navigation Component, but getting weird result.

When I navigate from DialogFragment to Fragment, background fragment is changing to target fragment with current dialog on top of it, instead of just moving to target fragment. Why I am getting this behavior or how to fix it?

By fixing I mean normal dialog behavior. Say, I have a dialog D on top of a fragment A and move to a fragment B from a button on D, the screen should show B. And when I pop back from B, it should go to previous stage of D on top of A.

Here is the navigation graph.

<navigation
xmlns:android="

http://schemas.android.com/apk/res/android"
xmlns:app="

http://schemas.android.com/apk/res-auto"
xmlns:tools="

http://schemas.android.com/tools"
android:id="@+id/home"
app:startDestination="@+id/titleScreen">

<fragment
android:id="@+id/titleScreen"
android:name="com.example.android.navigationadvancedsample.homescreen.Title"
android:label="@string/title_home"
tools:layout="@layout/fragment_title">
<action
android:id="@+id/action_title_to_about"
app:destination="@id/aboutScreen"/>
</fragment>
<dialog
android:id="@+id/aboutScreen"
android:name="com.example.android.navigationadvancedsample.homescreen.About"
android:label="@string/title_about"
tools:layout="@layout/fragment_about">
<action
android:id="@+id/action_aboutScreen_to_register"
app:destination="@id/register" />
</dialog>
<fragment
android:id="@+id/register"
android:name="com.example.android.navigationadvancedsample.formscreen.Register"
android:label="fragment_leaderboard"
tools:layout="@layout/fragment_leaderboard" />
</navigation>

If this is a bug in the library, we would appreciate if you could attach:
- Sample project to trigger the issue.
- A screenrecord or screenshots showing the issue (if UI related).

ezgif-2-fb1bfba2ffa0.gif

688 KB

View

Download

Comments

il...@google.com <il...@google.com> #2Jun 3, 2019 05:21PM

Assigned to il...@google.com.

Yigit, do you have time to fix it?

reemission of the same liveData is racy

mu...@gmail.com <mu...@gmail.com> #3Jun 5, 2019 04:32AM

yea i'll take it.

d....@gmail.com <d....@gmail.com> #4Jun 9, 2019 06:05PM

Thanks for the detailed analysis. This may not be an issue anymore since we've started using Main.immediate there but I' not sure; I'll try to create a test case.

an...@gmail.com <an...@gmail.com> #5Jun 19, 2019 07:14AM

just emitting same live data reproduces the issue.

@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}

issue.mp4

4 MB

Download

an...@gmail.com <an...@gmail.com> #6Jun 19, 2019 07:42AM

With 2.2.0-alpha04 (that use Main.immediate), the issue seems to be still there (I tested it by calling emitSource() twice, like your test case)

il...@google.com <il...@google.com> #7Jun 28, 2019 09:56PM

Marked as fixed.

yea sorry immediate does not fix it.
I actually have a WIP fix for it:

https://android-review.googlesource.com/c/platform/frameworks/support/+/1112186

if your case is the one i found (emitting same LiveData multiple times, as shown in #5) you can work around it by adding a dummy transformation.

val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData.map {it })
emitSource(subLiveData.map {it} )
}

j....@gmail.com <j....@gmail.com> #8Nov 7, 2019 08:54PM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit af12e75e6b4110f48e44ca121466943909de8f06
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Sep 03 12:58:11 2019

Fix coroutine livedata race condition

This CL fixes a bug in liveData builder where emitting same
LiveData source twice would make it crash because the second
emission registry could possibly happen before first one is
removed as source.

We fix it by using a suspending dispose function. It does feel
a bit hacky but we cannot make DisposableHandle.dispose async
and we do not want to block there. This does not mean that there
is a problem if developer disposes it manually since our emit
functions take care of making sure it disposes (and there is
no other way to add source to the underlying MediatorLiveData)

Bug: 140249349
Test: BuildLiveDataTest#raceTest_*

Change-Id: I0b464c242a583da4669af195cf2504e2adc4de40

M lifecycle/lifecycle-livedata-ktx/api/2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/current.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_current.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_current.txt
M lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt
M lifecycle/lifecycle-livedata-ktx/src/test/java/androidx/lifecycle/BuildLiveDataTest.kt

https://android-review.googlesource.com/1112186

https://goto.google.com/android-sha1/af12e75e6b4110f48e44ca121466943909de8f06

[Deleted User] <[Deleted User]> #9Jul 16, 2020 10:42AM

So what I can do to show the dialog again when the user press back on the fragment?

Is this still not possible?

ar...@gmail.com <ar...@gmail.com> #10Oct 11, 2020 10:22PM

So, what you suggest to do for this case? Are there alternative solutions?

il...@google.com <il...@google.com> #11Oct 12, 2020 06:14PM

Dialog destinations cannot be put on the back stack, that's still and will always be the case.

gu...@gmail.com <gu...@gmail.com> #12Aug 17, 2021 12:51PM

I think the only solution at present is to make fragment B a full dialog