Fixed
Status Update
No update yet.
Comments
ta...@gmail.com
I should add, I never explicitly set setReorderingAllowed to true. The documentation states
The default is false for applications targeting version versions prior to O and true for applications targeting O and later.
I'm not sure how pertinent this is with the support library fragments.Compile SDK and Target SDK versions are both 27.
The default is false for applications targeting version versions prior to O and true for applications targeting O and later.
I'm not sure how pertinent this is with the support library fragments.Compile SDK and Target SDK versions are both 27.
il...@google.com
to...@gmail.com
I can confirm that 27.1.0 has this bug. Downgrading to 27.0.2 worked for us (we came from 27.0.2).
It seems to be related to the fade transition, since setting the transition through the setTransition method of the FragmentTransaction results in the same behaviour.
It seems to be related to the fade transition, since setting the transition through the setTransition method of the FragmentTransaction results in the same behaviour.
il...@google.com
I can confirm this too for 27.1.0. Any workaround for this?
ta...@gmail.com
Seeing the same issue here with '.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE)' on Google Pixel 8.1.0. Attached a video comparing before and after.
My current workaround is to use a different transition such as TRANSIT_FRAGMENT_OPEN. It looks similar enough for me.
My current workaround is to use a different transition such as TRANSIT_FRAGMENT_OPEN. It looks similar enough for me.
il...@google.com
I also confirm this. Helps only return on 27.0.2
il...@google.com
I can confirm this bug. Reverting to 27.0.2 helped.
vo...@gmail.com
same here. reverte is the only workaround atm
kk...@google.com
I have the same issue. I had enter animation as fade_in and exit animation as fade_out. For me temporary solution is change exit animation to 0, transaction now looks almost the same as with fade_out exit animation
ku...@gmail.com
Thank you for reporting this bug. I am able to reproduce it. It was caused when fixing another bug and this error wasn't caught during testing.
ku...@gmail.com
Same issue. I had to roll back version to fix it
ku...@gmail.com
Fix has been submitted and should be in the next public release.
gs...@gmail.com
This bug has been fixed in Support Library 27.1.1.
Description
Callback order is changed when calling restartLoader.
The documentation of restartLoader Says: "If a loader with the same id has previously been started it will automatically be destroyed when the new loader completes its work. The callback will be delivered before the old loader is destroyed."
But new implementation does not that at all. It calls onLoaderReset then onCreateLoader then onLoadFinished. (Previous implementation was sometimes broken and never called onLoaderReset but at least there was no long duration where we have no data to display).
This is a major change because this means you can't keep the previous data during the load as it's invalidated but you have nothing to display since the new loader is not finished. Meaning empty screen on reload = quite bad UX.