IssueTracker

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.

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.

I can confirm this too for 27.1.0. Any workaround for this?

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.

I also confirm this. Helps only return on 27.0.2

I can confirm this bug. Reverting to 27.0.2 helped.

same here. reverte is the only workaround atm

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

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.

Same issue. I had to roll back version to fix it

Fix has been submitted and should be in the next public release.

This bug has been fixed in  Support Library 27.1.1.

In the app that I am working on, this issue only occurs when pressing back (unwinding the transaction). The problem is still reproducible in 27.1.1. Does 27.1.1 fix the problem for others?

About your side note: Calling restart on return from a child fragment that can have modified any number of data if often wanted and normal.
Specially when we are dealing with those viewpager and child fragments.

ViewPager backed by cursor, click open detail views that you can swipe to see any number of details, in each details view you can change things -> on reenter to viewpager fragment you restart the loader to have the uptodate data, even if the query have not changed.

Fragments with setUserVisibleHint=true will still start before those with it set to false (it is a two step process). While the Loader specific delay between the two steps is being removed, the ordering of creation/starting is not.

Can't edit but viewpager = recyclerview :)

Ok thanks for the detail.

Will this be released as a fast .X release or in the next normal scheduled cycle? (Just to have an idea if I should already start again using it to find other issues or have time for that).

This has been fixed for the next release, almost certainly as part of a fast .X release

So doing some more tests I see other differences in loaders behavior from before :(

Like onLoadFinished is being called when returning to fragment when it was not the case before (before any call to reload or init made)

And much more important a change in how onLoaderReset is now called.

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.

The onLoaderReset problem described in #20 makes working with CursorLoader and CursorAdapter suddenly very cumbersome in 27.1.0.

In order to avoid the "empty data" period of time after onLoaderReset, my extremely hacky workaround is to create a second identical loader, with a separate Loader ID, and flip between the two Loaders with each call to restartLoader, so that the previous Cursor remains alive until the next onLoadFinished callback.

I've opened https://issuetracker.google.com/issues/74135998 to follow that as per Ian request.

Before 27.1.0, loaders initialized with getSupportLoaderManager() used to receive a call to onStartLoading() while the activity was executing super.onStart(). This allowed synchronous loaders to initialize resources before the remaining body of onStart() executed. In 27.1.0, loaders no longer start loading until some time after onStart(). This change caused a few NPEs in our onStart() methods. Is this 27.1.0 behavior a violation of the "between onStart/onStop" contract?

I think https://issuetracker.google.com/issues/73976255#comment13 is referencing this same guarantee which appears to be broken.

With a bit more digging I found https://issuetracker.google.com/issues/74225064 which appears to reference and fix the exact issue that I mentioned in #23. Sorry for the noise.

please update your support libraries with 27.1.1

This bug has been fixed in  Support Library 27.1.1.

(Program type already present: android.arch.lifecycle.LiveData$LifecycleBoundObserver Message{kind=ERROR, text=Program type already present: android.arch.lifecycle.LiveData$LifecycleBoundObserver, sources=[Unknown source file], tool name=Optional.of(D8)})

solv this problam