Status Update
No update yet.
Comments
il...@google.com
We've been able to reproduce this, thanks.
It appears that the issue only occurs when Fragments have only a shared element transition and no enter/exit transition (depending on what direction the fragment is going).
Therefore an effective workaround is to define those transitions (even if there aren't technically any views they would be targeting), we get the right animation:
enterTransition = Fade()
exitTransition = Fade()
I assume you did not define any enter/exit transitions because you wanted any not shared elements to immediately disappear/appear (which seems...not great)? Or was there some other reason?
an...@framna.com
Thanks for looking into this.
The reason for not including the content transitions here was just that I did not think they were needed in the sample. In the actual app, we do have content transitions as well, so I think this sample may be illustrating a different bug, also related to backing out during a transition.
I've not had any luck reproducing my actual problem in a sample unfortunately, if I do I will file another issue for that. But from what I've seen, it appears that under specific conditions, if you back out during the transition (such that it re-uses the same fragment view), onMapSharedElements is not called on the shared element callback defined in the originating fragment (the one you're going back to). I know this is too vague to properly act on, so I need to experiment more and reproduce in a sample.
an...@framna.com
Was able to reproduce the other issue (which is similar to this but requires setReorderAllowed(true) and Transition 1.3.1), filed here
il...@google.com
Thanks, tracking the setReorderingAllowed(true)+Transition 1.3.1 issue separately makes a lot of sense.
As per setReorderingAllowed(true) or setReorderingAllowed(false) and with any version of AndroidX Transition, we never complete a shared element only operation. We need to fix that (probably by attaching a end listener on the shared element transition for the two fragments involved, skipping the end listener on the enter/exit transitions for any fragment that was part of the shared element transition). That's what we'll fix in this bug.
jb...@google.com
This has been fixed internally by other work (likely 1.3.0-beta01 release.
You can verify this by following the 6847503 and switching your fragment dependency to 1.3.0-SNAPSHOT.
Description
Version used: 1.3.0-SNAPSHOT, build 6743994
Devices/Android versions reproduced on: Emulator API 29, probably all
I have attached a sample project that illustrates the issue. In the sample, when you click on the red square, it will use a shared element transition into a second fragment. After half of the transition has passed, the back stack will be popped. The expected case is that the square returns to where it was (seen in attached video without_new_state_manager.mp4). Instead, the transition continues but appears to fade (this might be a default transition, not sure; seen in with_new_state_manager.mp4).
If you change the call to enableNewStateManager to false, you will see the right result, proving that the new state manager is responsible for the change in behavior.