React-native: com.facebook.react.uimanager.IllegalViewOperationException

[henrikra]

Is this a bug report?

Yeah.

Have you read the Contributing Guidelines?

Yeah.

Environment

Environment:
OS: macOS High Sierra 10.13.1
Node: 8.9.2
Yarn: 1.3.2
npm: 5.5.1
Watchman: 4.7.0
Xcode: Xcode 9.2 Build version 9C40b
Android Studio: 2.3 AI-162.4069837

Packages: (wanted => installed)
react: 16.0.0 => 16.0.0
react-native: 0.50.3 => 0.50.3

Steps to Reproduce

1. Have Android phone
2. Add LayoutAnimation to some of your components
3. App crashes randomly

Expected Behavior

The UIImplementation is trying to add some View which is not there yet.

Actual Behavior

1. Happening only on Android
2. OS versions having this crash so far:
   

Logs:

com.facebook.react.uimanager.IllegalViewOperationException Trying to add unknown view tag: 430 
    UIImplementation.java:396 com.facebook.react.uimanager.UIImplementation.setChildren
    UIManagerModule.java:310 com.facebook.react.uimanager.UIManagerModule.setChildren
    Method.java:-2 java.lang.reflect.Method.invoke
    JavaMethodWrapper.java:363 com.facebook.react.bridge.JavaMethodWrapper.invoke
    JavaModuleWrapper.java:162 com.facebook.react.bridge.JavaModuleWrapper.invoke
    NativeRunnable.java:-2 com.facebook.react.bridge.queue.NativeRunnable.run
    Handler.java:789 android.os.Handler.handleCallback
    Handler.java:98 android.os.Handler.dispatchMessage
    MessageQueueThreadHandler.java:31 com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage
    Looper.java:164 android.os.Looper.loop
    MessageQueueThreadImpl.java:194 com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run
    Thread.java:764 java.lang.Thread.run

Backstory

I have developed with RN for over a year now. And this crash has been there always. Some people say it is related to LayoutAnimation but I have gotten it already before that. Recently there were fix commits to similar issue https://github.com/facebook/react-native/commit/f2c6877b91963878f36ec42f5f865427bc69488c But I think they don't fix this because looks like the lines that can have this crash are here: https://github.com/facebook/react-native/search?utf8=%E2%9C%93&q=%22Trying+to+add%22&type=

This crash has been so long in RN so maybe it would be time to fix it? Tell me if there is anything I could do for help :)

Reproducible Demo

Unfortenately I can't reproduce this on my Android :(

Similar issues:
https://github.com/facebook/react-native/issues/13984
https://github.com/facebook/react-native/issues/17092
https://github.com/facebook/react-native/issues/16412
https://github.com/facebook/react-native/issues/14944
https://github.com/facebook/react-native/issues/14768
https://github.com/facebook/react-native/issues/10745

[a6051529]

Any solution to this problem? It causes random crash on the app.

[mauscoelho]

+1

[linxiaoru]

+1

[hpyfei]

+1

[filipef101]

Having same issue, some times random crash on navigation reset

EDIT: I think it was because I'm using wix navigation (react-native-navigation)
My fork of it has it fixed, check the commit were I did it and patch your repo if you are using it

[DanGDroid]

same here

15698

[iinsta]

Same:

com.facebook.react.uimanager.IllegalViewOperationException: Trying to add unknown view tag: 170
    at com.facebook.react.uimanager.UIImplementation.setChildren(UIImplementation.java:396)
    at com.facebook.react.uimanager.UIManagerModule.setChildren(UIManagerModule.java:310)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:363)
    at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:162)
    at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
    at android.os.Handler.handleCallback(Handler.java:754)
    at android.os.Handler.dispatchMessage(Handler.java:95)
    at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:31)
    at android.os.Looper.loop(Looper.java:163)
    at com.facebook.react.bridge.queue.MessageQueueThreadImpl$3.run(MessageQueueThreadImpl.java:194)
    at java.lang.Thread.run(Thread.java:760)

[filipef101]

@iinsta Check my comment I edited above, I don't remember well what caused my issue but should be it

[filipef101]

May also be because you have a modal or lightbox that needs to be dismissed first

[iinsta]

@filipef101 I will try it! And Thank you!

[react-native-bot]

Thanks for posting this! It looks like you may not be using the latest version of React Native, v0.53.0, released on January 2018. Can you make sure this issue can still be reproduced in the latest version?

I am going to close this, but please feel free to open a new issue if you are able to confirm that this is still a problem in v0.53.0 or newer.

_{How to Contribute • What to Expect from Maintainers}

[ssuchanowski]

Can anyone confirm that it has been fixed in most recent RN version?

[filipef101]

Its not a react native issue, check your code

[ssuchanowski]

Any hint on where to look? I have a hybrid Java + RN app and so far I cannot reproduce it on my devices (different ones are shipping now) but we get a lot of those exceptions on production.

[filipef101]

what navigation are you using?

[ssuchanowski]

Whole navigation is done in native code.

[filipef101]

maybe its some non dismissed light box or modal, I also don't remember exactly what caused it :/
but I somehow solved

[filipef101]

I was doing a navigation reset with a modal or lightbox open, after dismissing it before reseting nav it was fixed, but Im not sure if thats the cause

[filipef101]

And if you are going to update react, go to 0.53 instead of 0.54 (less problems)

[ssuchanowski]

ok, thanks!

[Frank1234]

Here is a very simple demo project that reproduces this bug: https://github.com/facebook/react-native/issues/19233 . Sadly, it reproduces not only this bug, but many other bugs as well, in a random manner. But clicking the button in the app a few times will definitely cause this exact exception.

[SudoPlz]

I managed to spot exactly what's causing that problem in react-native.

So what happens behind the scenes is, react-native is trying to manipulate the shadowNode list at the same time some other thread is manipulating it.

Specifically UIImplementation manipulates that list with the following methods

1) createView
2) setChildren
3) manageChildren
4) removeRootShadowNode

so if any of those get invoked at the same time, there's a really high chance that the app will crash.

In our app we fixed that issue by providing a custom UIImplementation that looks like this:

https://gist.github.com/SudoPlz/23ea2dee9772cb39e1e742034cdf8b98

as you can see we don't allow those UIImplementation methods to run unsynchronised anymore.

We could constantly reproduce the issue on our end, but now that's totally fixed.
We pass the new UIImplementation provided through this method here.

I hope this post helps others, because it really took me A CRAZY amount of time to figure this out.

I really wonder though, is there a reason the facebook team kept that code unsynchronized?

[SudoPlz]

If you don't know how to pass a new UIImplementationProvider you have to go to your MainApplication.java file, find the creation of ReactNativeHost:

private final ReactNativeHost mReactNativeHost = new ReactNativeHost(this) {
    @Override
    public boolean getUseDeveloperSupport() {
      return BuildConfig.DEBUG;
    }
...bla bla blah

and add the following function:

protected UIImplementationProvider getUIImplementationProvider() {
    return new YourCustomUIImplementationProvider();
}

so that it now looks like this:

private final ReactNativeHost mReactNativeHost = new ReactNativeHost(this) {
    @Override
    public boolean getUseDeveloperSupport() {
      return BuildConfig.DEBUG;
    }

    protected UIImplementationProvider getUIImplementationProvider() {
        return new YourCustomUIImplementationProvider();
    }
...bla bla blah

[brunolemos]

@sudoplz if you want the core team to do something you will probably need to create a new issue or PR; they may not look at closed issues.

This code should be the default, right? I don't think users should have to do anything on their end to prevent this crash.

[SudoPlz]

Yeah, I think this should be default behaviour.. I'll open a PR later on.

[Dantalion]

@SudoPlz Thank you very much and great work! I hope that your PR will be accepted asap!

[wesleymooiman]

@SudoPlz did you create a pr to fix this problem?

[SudoPlz]

@wesleymooiman ^

[beausmith]

It seems Android doesn't like converting non-Boolean values into booleans. So I'm now ensuring that all values which I'm using as booleans are in fact, booleans.

I have changed all occurrences similar to this where foo may not be true or false:

{foo && <MyComponent />}

…into one of these which converts foo into a boolean if it is not:

{!!foo && <MyComponent />}
{Boolean(foo) && <MyComponent />}