NavHostFragment crashes when a custom DialogNavigator is used [175979140]

Fixed

Bug

Status Update

No update yet.

Description

ru...@gmail.com

created issue #1

Dec 20, 2020 09:20PM

Component used: Navigation
Version used: 2.3.2

Caused by:
- NavHostFragment looks up a DialogFragmentNavigator in "onAttachFragment" and no null check is done
- A custom Dialog fragment navigator can't extend from DialogFragmentNavigator as it's a final class

Commit that introduced this:

https://android.googlesource.com/platform/frameworks/support/+/2674709cf3f9d2d46c9bcee55ec01eb115143aaa

Can the new API be used instead to fix this issue in the next alpha/beta release?
In alternative, do you suggest other workaround or should we wait and stay in 2.3.1 until this is fixed?

Comments

il...@google.com <il...@google.com> #2Dec 23, 2020 11:57PM

Thanks for the report - do you have any reproduction steps?

ru...@gmail.com <ru...@gmail.com> #3Dec 28, 2020 06:55PM

Nevermind, this has been fixed and will be available in an upcoming release.

ru...@gmail.com <ru...@gmail.com> #4Jan 5, 2021 05:09PM

An unfortunate side effect of this seems to be that the adapter is set to null before any pending fragment animations are completed.

In my project I add a PreferenceFragmentCompat to the backstack, specifying custom enter and exit animations. Now, when the user presses the back button I call FragmentManager.popBackStack() which in turn starts the custom exit animation.

The problem is that popBackstack() internally calls onDestroyView() on the PreferenceFragmentCompat to be removed. The PreferenceFragmentCompat calls unbindPreferences() which calls getListView().setAdapter(null).

The effect is that the list of preference items is cleared instantly before the exit animation even starts! This causes a white flicker and is clearly noticeable, the preference items disappear, then the view fades out.

Could you prevent setAdapter(null) from being called in this scenario? Maybe unregister the data observer instead?

ru...@gmail.com <ru...@gmail.com> #5Feb 8, 2021 11:04PM

Since the Fragment 1.2.0-alpha02 release fragments wait until exit animations are complete before onDestroyView() is called so this should not be an issue in any current Fragment versions.

Please file a bug against Fragments the with a sample project that reproduces this issue and we will be happy to take a look at what's going on.

il...@google.com <il...@google.com> Apr 6, 2021 07:45PM

Assigned to il...@google.com.

ap...@google.com <ap...@google.com> #6Apr 7, 2021 04:10PM

I can confirm that using fragment 1.2.2 resolves the issue, thank you!

Without an explicit dependency declaration version 1.1.0 was still used (transient dependency of appcompat 1.1.0).

il...@google.com <il...@google.com> #7Apr 7, 2021 05:31PM

Marked as fixed.

In the upcoming Navigation 2.4.0-alpha01, we've updated our Fragment dependency such that we can use the Fragment 1.3.0's API of FragmentOnAttachListener to handle the case where previously the NavHostFragment needed to be involved. Thus, NavHostFragment no longer needs to cast the Navigator returned by the dialog name to DialogNavigator.

As a workaround, your custom Navigator can use any name other than dialog (say, singleDialog) and it'll work just fine if you use that instead of dialog.

ru...@gmail.com <ru...@gmail.com> #8Apr 7, 2021 05:49PM

Thank you for fixing this. Would singleDialog have to be also used in the navigation resources files? I didn't know we could create custom navigation targets with different names outside of dialog, fragment and activity

il...@google.com <il...@google.com> #9Apr 7, 2021 05:54PM

The default DialogFragmentNavigator, FragmentNavigator, and ActivityNavigator use the exact same @Navigator.Name API as is available to every custom Navigator (there's no special casing on the Navigation library side), so yes, it can also be used from XML.