Update LithoView.java to fix crash

[wsdwsd08290829]

I cannot recreate this but here is the crash trace and analysis for the fix:

Crash Traces:
com.facebook.litho.LithoMetadataExceptionWrapper: Clearing the LithoView while the ComponentTree is attached
at com.facebook.litho.ComponentTree.clearLithoView(ComponentTree.java:1122)
at com.facebook.litho.LithoView.setComponentTree(LithoView.java:854)
at com.facebook.litho.LithoView.setComponentTree(LithoView.java:810)
at com.facebook.litho.widget.RecyclerBinder$DefaultRecyclerBinderAdapterDelegate.onViewRecycled(RecyclerBinder.java:4223)
at com.facebook.litho.widget.RecyclerBinder$InternalAdapter.onViewRecycled(RecyclerBinder.java:4462)
at android.support.v7.widget.RecyclerView$Recycler.dispatchViewRecycled(RecyclerView.java:7580)
at android.support.v7.widget.RecyclerView$Recycler.addViewHolderToRecycledViewPool(RecyclerView.java:7342)
at android.support.v7.widget.RecyclerView$Recycler.recycleViewHolderInternal(RecyclerView.java:7293)
at android.support.v7.widget.RecyclerView$Recycler.recycleView(RecyclerView.java:7168)
at android.support.v7.widget.RecyclerView$LayoutManager.removeAndRecycleViewAt(RecyclerView.java:9916)
at android.support.v7.widget.RecyclerView$LayoutManager.removeAndRecycleAllViews(RecyclerView.java:11325)
at android.support.v7.widget.RecyclerView.removeAndRecycleViews(RecyclerView.java:1328)
at android.support.v7.widget.RecyclerView.setAdapterInternal(RecyclerView.java:1352)
at android.support.v7.widget.RecyclerView.setAdapter(RecyclerView.java:1310)
at com.facebook.litho.widget.RecyclerBinder.unmount(RecyclerBinder.java:3337)
at com.facebook.litho.sections.widget.SectionBinderTarget.unmount(SectionBinderTarget.java:86)
at com.facebook.litho.sections.widget.SectionBinderTarget.unmount(SectionBinderTarget.java:36)
at com.facebook.litho.widget.RecyclerSpec.onUnmount(RecyclerSpec.java:337)
at com.facebook.litho.widget.Recycler.onUnmount(Recycler.java:562)
at com.facebook.litho.Component.unmount(Component.java:407)
at com.facebook.litho.MountState.updateMountedContent(MountState.java:1097)
at com.facebook.litho.MountState.updateMountItemIfNeeded(MountState.java:801)
at com.facebook.litho.MountState.mount(MountState.java:408)
at com.facebook.litho.LithoView.mount(LithoView.java:1686)
at com.facebook.litho.ComponentTree.mountComponentInternal(ComponentTree.java:962)
at com.facebook.litho.ComponentTree.mountComponent(ComponentTree.java:932)
at com.facebook.litho.ComponentTree.mountComponentIfNeeded(ComponentTree.java:809)
at com.facebook.litho.ComponentTree.layout(ComponentTree.java:1290)
at com.facebook.litho.LithoView.performLayoutInternal(LithoView.java:710)
at com.facebook.litho.LithoView.performLayout(LithoView.java:676)
at com.facebook.litho.ComponentHost.onLayout(ComponentHost.java:940)
at android.view.View.layout(View.java:24475)
at android.view.ViewGroup.layout(ViewGroup.java:7383)
at android.widget.LinearLayout.setChildFrame(LinearLayout.java:1829)

Reasoning
The issue arises from a race condition on the main thread. The sequence of RecyclerView callbacks (onDetach, onViewRecycled, etc.) for one view can be interleaved with callbacks for another view (onAttach, setComponentTree), leading to an object state that the original code didn't anticipate.

Let's walk through the exact sequence of events that leads to the crash:

LithoView A is on screen. It's attached to the window and is displaying content using a ComponentTree (let's call it ComponentTree T).

lithoViewA.mIsAttached is true.
componentTreeT.mIsAttached is true.
componentTreeT.getLithoView() points to lithoViewA. You scroll, and LithoView A moves off-screen. The RecyclerView detaches it from the window.

lithoViewA.onDetach() is called.
Inside onDetach(), mComponentTree.detach() is called. Crucially, componentTreeT.mIsAttached is now false. The ComponentTree is immediately reused. A new view, LithoView B, scrolls onto the screen. To be efficient, the RecyclerBinder gives it the now-available ComponentTree T.

lithoViewB.setComponentTree(componentTreeT) is called. Inside this, componentTreeT.setLithoView(lithoViewB) is called. Now componentTreeT thinks its view is lithoViewB. lithoViewB is attached to the window, so lithoViewB.onAttach() is called. Inside onAttach(), componentTreeT.attach() is called. Crucially, componentTreeT.mIsAttached is now true again, but it's attached to lithoViewB. The recycling process for LithoView A continues. The RecyclerView now calls onViewRecycled for the item that was holding LithoView A. This eventually calls lithoViewA.setComponentTree(null).

The crash occurs inside lithoViewA.setComponentTree(null):

lithoViewA still holds its reference to componentTreeT. It executes the code block from your original question. First, if (mIsAttached) is checked. lithoViewA.mIsAttached is false (from step 2), so mComponentTree.detach() is skipped. Then, mComponentTree.clearLithoView() is called.
Inside clearLithoView(), there's an assertion: if (mIsAttached) { throw ... }. This check is on componentTreeT.mIsAttached, which was set to true in step 3 when it was attached to lithoViewB. The exception is thrown because the ComponentTree is, in fact, attached—just not to the view that's trying to clear it. Even though the code is synchronous, the ComponentTree object has been "stolen" and its state has been changed by another part of the system (lithoViewB) between the time lithoViewA was detached and the time its recycling logic fully completed.

Summary

Changelog

Test Plan

[facebook-github-bot]

Hi @wsdwsd08290829!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!