NavBackStackEntry lifecycle not updated correctly when there are multiple FloatingWindow destinations on the back stack [287505132]

Fixed

Bug

Status Update

No update yet.

Description

ga...@gmail.com

created issue #1

Jun 16, 2023 07:18PM

Component used: Navigation
Version used: 2.6.0
Devices/Android versions reproduced on: Emulator Android 13

Very simple scenario for demo purposes:
1. MainFragment navigates to Dialog1Fragment
2. Dialog1Fragment navigates to Dialog2Fragment
3. Dialog2Fragment navigates back

This will result in the lifecycle of Dialog1Fragment's NavBackStackEntry to go back into `ON_START` but it will never go back to `ON_RESUME` even though it is now the top destination on the stack.

I've attached a small sample project with these 3 fragments

test.zip

113 KB

Download

Comments

ga...@gmail.com <ga...@gmail.com> #2Jun 16, 2023 07:45PM

Thanks for filling this, HiltViewModelFactory wraps around a SavedStateViewModelFactory which is also the default one for non Hilt injected Fragments and Activities, it seems there is some key conflicts, I'll investigate and comer back with more info soon, thanks for the sample app!

jb...@google.com <jb...@google.com> Jun 16, 2023 08:08PM

Assigned to cl...@google.com.

ga...@freeletics.com <ga...@freeletics.com> #3Aug 1, 2023 06:19AM

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

commit d76172ec45a778efe5f46b6ad1a50ae24241d14d
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Tue Jun 16 14:50:23 2020

Avoid SavedStateHandle key conflict in HiltViewModelFactory.

When delegating to the SavedStateViewModelFactory to create
ViewModels that are not Hilt injected, the factory will attempt
to retrieve a SavedStateHandler using a controller with the same
key as the SavedStateHandle passed into the abstract create() method
of AbstractSavedStateViewModelFactory for which the
HiltViewModelFactory implements. Therefore causing a key conflict.

In this change we avoid the key conflict collision by prefixing the
before delegating to SavedStateViewModelFactory. Since ViewModels
will be either create by one or the other factory, it is safe to
mangle the key. Meanwhile, even though the key is also used to
add a tag to the ViewModel for cleanup, the tag is only added
if the key used is not present. When SavedStateViewModelFactory
tags the ViewModel and then a second time in once
AbstractSavedStateViewModelFactory#create() returns, the tag
is not overridden (lucky us).

This fixes a bug when mixing vanilla ViewModels and Hilt injected
ones.

Bug: 158737069
Test: ViewModelApp Integration Tests
Change-Id: I86ae254c2f26795c900317d42041319fd279e545

M buildSrc/src/main/kotlin/androidx/build/LibraryVersions.kt
M hilt/hilt-lifecycle-viewmodel/src/main/java/androidx/hilt/lifecycle/HiltViewModelFactory.java
M hilt/integration-tests/viewmodelapp/build.gradle
A hilt/integration-tests/viewmodelapp/src/androidTest/java/androidx/hilt/integration/viewmodelapp/ActivityInjectionTest.kt
A hilt/integration-tests/viewmodelapp/src/androidTest/java/androidx/hilt/integration/viewmodelapp/BaseActivityInjectionTest.kt
A hilt/integration-tests/viewmodelapp/src/androidTest/java/androidx/hilt/integration/viewmodelapp/BaseFragmentInjectionTest.kt
A hilt/integration-tests/viewmodelapp/src/androidTest/java/androidx/hilt/integration/viewmodelapp/Bindings.kt
A hilt/integration-tests/viewmodelapp/src/androidTest/java/androidx/hilt/integration/viewmodelapp/FragmentInjectionTest.kt
A hilt/integration-tests/viewmodelapp/src/androidTest/java/androidx/hilt/integration/viewmodelapp/MyViewModels.kt
A hilt/integration-tests/viewmodelapp/src/androidTest/java/androidx/hilt/integration/viewmodelapp/TestRunner.kt
A hilt/integration-tests/viewmodelapp/src/debug/AndroidManifest.xml

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

cl...@google.com <cl...@google.com> #4Aug 30, 2023 05:38PM

Accepted by cl...@google.com.

A fix for this will be available in alpha02

Message last modified on Aug 30, 2023 06:04PM

ap...@google.com <ap...@google.com> #5Aug 31, 2023 07:26PM

Project: platform/frameworks/support
Branch: androidx-main

commit 34427f031ebd1b5e3336137c89f532f004aa71f9
Author: Clara Fok <clarafok@google.com>
Date: Wed Aug 30 14:17:10 2023

Fix DialogFragment not marked transition complete

When navigating to new DialogFragment, the current open DialogFragment (outoing entry) is marked as transitioning. Likewise, when popping a DialogFragment, the incoming entry is marked as transitioning. However in both cases, the entry is not marked complete after navigation/pop. In the second case, it prevents the incoming entry from moving to RESUMED state.

Now we ensure to remove the entries from its transient transitioning state so it can move to proper lifecycle state.

Test: ./gradlew navigation:navigation-fragment:cC
Bug: 287505132
Change-Id: I3b866a44291e7bd7af742562ae0619cd83929a1a

M navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/DialogFragmentNavigatorTest.kt
M navigation/navigation-fragment/src/main/java/androidx/navigation/fragment/DialogFragmentNavigator.kt

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

cl...@google.com <cl...@google.com> #6Aug 31, 2023 07:52PM

Marked as fixed.

Fixed internally and will be available in navigation 2.7.3

na...@google.com <na...@google.com> #7Sep 20, 2023 07:16PM

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.navigation:navigation-fragment:2.7.3

na...@google.com <na...@google.com> #8Jan 24, 2024 07:53PM