When an Activity has child Fragments in a container, and navigation is executed on the Activity's NavigationHandle, child history can be overwritten

[isaac-udy]

Problem:
Given an Activity with a container to hold Fragments, imagine a scenario where the following navigation is executed (assuming that all Fragments are accepted by the Activity's container):
Activity executes forward action to Fragment A
Fragment A executes forward action to Fragment B
Fragment B executes forward action to Fragment C
Activity executes forward action to Fragment D

If you press the "back" button while Fragment D is active, Fragment D would close back to the Activity, leaving the container empty, because technically it was the Activity that opened Fragment D, so Fragment D does not re-open Fragment C into the container.

I feel like this behaviour isn't quite right, and I think that closing Fragment D should go back to Fragment C. I am thinking about adjusting the navigation system, so that if a navigation action is executed, that action will be passed to the currently active destination for execution. In the example above, that would mean when the Activity goes forward to Fragment D, the Activity would find the currently active Fragment C, and ask Fragment C's navigation handle to actually execute the instruction.

@mgod I'd be interested in your thoughts as to what should happen here, or if you see any problems with my proposed changes.

[mgod]

I think this sounds like an improvement. I'm having some trouble thinking through how this would interact with launching activities/fragments without containers, but I've been using a similar pattern to manage some issues around fragment state. In my case I'm having to manually keep track of which navigation actions will open contained fragments vs not.

[mgod]

Yes, I think this is how it should work. I'd still want results to be handled by the Activity even if the primary navigation fragment is executing the instruction.

From our other thread, I'm wondering if fragment navigation should be executed by the parentFragment if one is present for similar reasons. Hopefully my example there shows what I'm running into.

[isaac-udy]

This issue was tricker to resolve than it seemed at first. The Enro 1.0 Fragment/Container relationship was modelled in a way that made this difficult to solve without rethinking this relationship. Luckily, I have already been working on a 2.0 version of Enro, which changes the Fragment/Container relationship. This problem is solved in Enro 2.0.

Enro 2.0 is currently in alpha if you want to check this out.

Enro 2.0 is backwards compatible with Enro 1.0, and due to the complexity of solving this issue without introducing regressions in Enro 1.0, I'm going to close this issue and mark it as "resolved (next major)".