[email protected] throws error messages at certain points in our app with Chrome 54 (Chrome 53 and other browsers work).
I wasn't able to pinpoint the cause.
DOMChildrenOperations.js?8e2a:41 Uncaught TypeError: Failed to execute 'insertBefore' on 'Node': parameter 1 is not of type 'Node'.
Also now ran into this one, exclusively in Chrome 54:
Uncaught Error: processUpdates(): Unable to find child 1 of element. This probably means the DOM was unexpectedly mutated (e.g., by the browser), usually due to forgetting a <tbody> when using tables, nesting tags like <form>, <p>, or <a>, or using non-SVG elements in an <svg> parent. Try inspecting the child nodes of the element with React ID
Thanks for the issue report @MoeSattler!
[email protected] throws error messages at certain points in our app with Chrome 54 (Chrome 53 and other browsers work).
Can you test with the latest version of React, or at least something newer? I know this can be hard to do with large applications, but it might be an issue we've already resolved
I wasn't able to pinpoint the cause.
Unfortunately, there's not a lot we can do without a reproducible test case. If you could share a minimal test case that exhibits the issue, it would be useful. But again, it might be something we've already resolved in a newer release.
This is only impacting dev builds for my app. Is anyone experiencing this in dist builds? Also, any ideas on why this would only impact dev builds?
We are getting the same errors mentioned above. We are trying to upgrade, but the APIs from 0.14 have changed somewhat and that is requiring us to rebuild a lot of our app.
Yes, we encounter this same issue, the stack trace shows that the markupIndex is NaN in this line
https://github.com/facebook/react/blob/0.14-stable/src/renderers/shared/reconciler/ReactMultiChild.js#L65
Placing a conditional debugger on this line resolve this issue mysteriously, and upgrading react to @15.3.2 fix it, since the ReactMultiChild is changed in @15.3.2.
It happens in our code base where there are a lot of react components rendered ( for example large table with pagination), and where we render other non react component inside react component, and where we use setInterval to call react rendering function constantly.
Some issues occur in PC and chrome54, and some in mac and chrome54. All are working fine for chrome53.
However, since 0.14.8 is widely used in production code, and it is still supported, we would like to see a fix for that. Thanks!
My dev team is facing the exact issue. Chrome 54 only, only in dev. Prod/dist works great. I can reproduce it 100% of the time. Seems to have on redraws of components in React. If I take 3 actions that render components, the third one will throw the error every time.
Same for us since chrome upgrade last friday.
Same here. Using React 0.14.6, error occurs in Chrome 54.
Debugging we see that here we get childNode
as NULL
which triggers the error.
Going back the stack trace in this point (manually adding a try/catch
and also _breakpoints_) I can see that in here update.markupIndex
has the value NaN
.
That update
variable is at this moment just like this:
Adding to this: I noticed that the when this happens, the updates
array received in here has always a pair for this NULL
INSERT_MARKUP: a similar NULL
but with type REMOVE_NODE.
Interestingly enough, I was able to narrow down one case to a really small piece of a component of mine that triggers this. Simply having something like this:
let content = <div> ... </div>;
return (
<div>
<div> ... </div>
<div> {content} </div>
</div>
);
Then after some tests I was able to see that {content}
provokes the error (without it, it breaks in other places). So I was able to avoid the error happening in this part by doing:
let content = <div> ... </div>;
return (
<div>
<div> ... </div>
<div> {content} </div>
</div>
);
But then it breaks with the same error again in other part, now within an external component (_griddle-react^0.3.1_).
FYI - I am trying to work in a reproducible scenario for this.
Same here in our company using react with webpack dev server after upgrading to Chrome 54. On production works perfectly fine. Occurs when rerendering components. [email protected].
Having the same issue, chromium on Arch Linux. It seems like it's probably a V8 bug, since the only way I can see markupIndex
gets set is from the result of push()
, and if I place a breakpoint around that it doesn't seem to happen (i.e. return NaN), classic Heisenbug. So, probably wonky low-level stuff.
I would bet this is due to the V8 bug mentioned by @developit on Twitter where push
ends up returning the value pushed instead of the index.
If that's the case then the fix has already been merged and should be pushed in the next stable release, meaning this wouldn't be actionable on our end and we can just wait for the fix to land 馃憤
Yup. Canary should work fine, decent way to verify you're seeing the Turbofan push issue.
Guess this issue could be confirmed since lots have met the same situation. Is there anyone who has fixed it by simply upgrading react
?
There was a patch release for Chrome 54 (while Windows seems to already have Chrome 55).
That fixed the issue for us.
upgrading chrome fixed it
Thanks for verifying @MoeSattler!
Confirmed. I upgraded to Chrome version 54.0.2840.71 (64-bit) and the problem has disappeared.
+1 happening for me also, Can you someone confirm without updating chrome on prod version of react 0.14.8 will run smooth. @Aweary @MoeSattler
Most helpful comment
Same here. Using React 0.14.6, error occurs in Chrome 54.
Debugging we see that here we get
childNode
asNULL
which triggers the error.Going back the stack trace in this point (manually adding a
try/catch
and also _breakpoints_) I can see that in hereupdate.markupIndex
has the valueNaN
.That
update
variable is at this moment just like this:Adding to this: I noticed that the when this happens, the
updates
array received in here has always a pair for thisNULL
INSERT_MARKUP: a similarNULL
but with type REMOVE_NODE.Interestingly enough, I was able to narrow down one case to a really small piece of a component of mine that triggers this. Simply having something like this:
Then after some tests I was able to see that
{content}
provokes the error (without it, it breaks in other places). So I was able to avoid the error happening in this part by doing:But then it breaks with the same error again in other part, now within an external component (_griddle-react^0.3.1_).
FYI - I am trying to work in a reproducible scenario for this.