Question:
: However, given: I'm getting a log when I click on the unprofiled counter. Reproduction: Am I misunderstanding this API, or is this a bug?
As the state is being updated by Counter function which is being called on both the profiled and unprofiled counter, is causing re render and is being called both the times.
Thanks but I'm pretty sure that the way it's documented (and what would be sensible) it shouldn't be operating like that. Also, I tried making a separate component instead of using the same one and I got the same result.
At a quick glance it does look unexpected. Don't have time to dig in further at the moment though.
It seems that this occurs for elements which have same type with greater or equal depth in same tree. See:
I don't think it has anything to do with the element type, but where they are declared relative to where the tags are defined. It looks like for a subtree that belongs to a single owner- rendering further down in the subtree will cause the Profiler higher up to call . Given the above example:
This does not look to be hooks-specific, nor is it a recent regression. (Same behavior is exhibited for class components in the earliest release of the Profiler component- v16.5.)
It seems that the is always marked as in phase.
Thanks

render() { instance = this; return ( <del> <> </del> <ins> <React.Fragment> </ins> <Yield value="first" /> {this.state.count} <Yield value="last" /> <del> </> </del> <ins> </React.Fragment> </ins> ); } }


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Bailing out doesn't work properly in lazy components with default props. It seems we're incorrectly . If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: What is the expected behavior? In the example above, shouldn't have been called when the button is clicked. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
Can you turn this into a failing test please?
Sure.
Send a PR?
OK
Feel free to add a fix if you know where the bug is

); if (__DEV__) { const inst = workInProgress.stateNode; <del> if (inst.props !== nextProps) { </del> <ins> if (shouldUpdate && inst.props !== nextProps) { </ins> if (!didWarnAboutReassigningProps) { console.error( 'It looks like %s is reassigning its own `this.props` while rendering. ' +


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Bailing out doesn't work properly in lazy components with default props. It seems we're incorrectly . If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: What is the expected behavior? In the example above, shouldn't have been called when the button is clicked. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
Can you turn this into a failing test please?
Sure.
Send a PR?
OK
Feel free to add a fix if you know where the bug is

cloneUpdateQueue(current, workInProgress); <del> const oldProps = workInProgress.memoizedProps; instance.props = </del> <ins> const unresolvedOldProps = workInProgress.memoizedProps; const oldProps = </ins> workInProgress.type === workInProgress.elementType <del> ? oldProps : resolveDefaultProps(workInProgress.type, oldProps); </del> <ins> ? unresolvedOldProps : resolveDefaultProps(workInProgress.type, unresolvedOldProps); instance.props = oldProps; const unresolvedNewProps = workInProgress.pendingProps; </ins> const oldContext = instance.context; const contextType = ctor.contextType;


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Bailing out doesn't work properly in lazy components with default props. It seems we're incorrectly . If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: What is the expected behavior? In the example above, shouldn't have been called when the button is clicked. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
Can you turn this into a failing test please?
Sure.
Send a PR?
OK
Feel free to add a fix if you know where the bug is

(typeof instance.UNSAFE_componentWillReceiveProps === 'function' || typeof instance.componentWillReceiveProps === 'function') ) { <del> if (oldProps !== newProps || oldContext !== nextContext) { </del> <ins> if ( unresolvedOldProps !== unresolvedNewProps || oldContext !== nextContext ) { </ins> callComponentWillReceiveProps( workInProgress, instance,


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Bailing out doesn't work properly in lazy components with default props. It seems we're incorrectly . If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: What is the expected behavior? In the example above, shouldn't have been called when the button is clicked. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
Can you turn this into a failing test please?
Sure.
Send a PR?
OK
Feel free to add a fix if you know where the bug is

newState = workInProgress.memoizedState; if ( <del> oldProps === newProps && </del> <ins> unresolvedOldProps === unresolvedNewProps && </ins> oldState === newState && !hasContextChanged() && !checkHasForceUpdateAfterProcessing()


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Bailing out doesn't work properly in lazy components with default props. It seems we're incorrectly . If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: What is the expected behavior? In the example above, shouldn't have been called when the button is clicked. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
Can you turn this into a failing test please?
Sure.
Send a PR?
OK
Feel free to add a fix if you know where the bug is

// effect even though we're bailing out, so that cWU/cDU are called. if (typeof instance.componentDidUpdate === 'function') { if ( <del> oldProps !== current.memoizedProps || </del> <ins> unresolvedOldProps !== current.memoizedProps || </ins> oldState !== current.memoizedState ) { workInProgress.effectTag |= Update;


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Bailing out doesn't work properly in lazy components with default props. It seems we're incorrectly . If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: What is the expected behavior? In the example above, shouldn't have been called when the button is clicked. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
Can you turn this into a failing test please?
Sure.
Send a PR?
OK
Feel free to add a fix if you know where the bug is

} if (typeof instance.getSnapshotBeforeUpdate === 'function') { if ( <del> oldProps !== current.memoizedProps || </del> <ins> unresolvedOldProps !== current.memoizedProps || </ins> oldState !== current.memoizedState ) { workInProgress.effectTag |= Snapshot;


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Bailing out doesn't work properly in lazy components with default props. It seems we're incorrectly . If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: What is the expected behavior? In the example above, shouldn't have been called when the button is clicked. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
Can you turn this into a failing test please?
Sure.
Send a PR?
OK
Feel free to add a fix if you know where the bug is

expect(root).toMatchRenderedOutput('SiblingB'); }); <ins> it('resolves defaultProps without breaking bailout due to unchanged props and state, #17151', async () => { class LazyImpl extends React.Component { static defaultProps = {value: 0}; render() { const text = `${this.props.label}: ${this.props.value}`; return <Text text={text} />; } } const Lazy = lazy(() => fakeImport(LazyImpl)); const instance1 = React.createRef(null); const instance2 = React.createRef(null); const root = ReactTestRenderer.create( <> <LazyImpl ref={instance1} label="Not lazy" /> <Suspense fallback={<Text text="Loading..." />}> <Lazy ref={instance2} label="Lazy" /> </Suspense> </>, { unstable_isConcurrent: true, }, ); expect(Scheduler).toFlushAndYield(['Not lazy: 0', 'Loading...']); expect(root).not.toMatchRenderedOutput('Not lazy: 0Lazy: 0'); await Promise.resolve(); expect(Scheduler).toFlushAndYield(['Lazy: 0']); expect(root).toMatchRenderedOutput('Not lazy: 0Lazy: 0'); // Should bailout due to unchanged props and state instance1.current.setState(null); expect(Scheduler).toFlushAndYield([]); expect(root).toMatchRenderedOutput('Not lazy: 0Lazy: 0'); // Should bailout due to unchanged props and state instance2.current.setState(null); expect(Scheduler).toFlushAndYield([]); expect(root).toMatchRenderedOutput('Not lazy: 0Lazy: 0'); }); it('resolves defaultProps without breaking bailout in PureComponent, #17151', async () => { class LazyImpl extends React.PureComponent { static defaultProps = {value: 0}; state = {}; render() { const text = `${this.props.label}: ${this.props.value}`; return <Text text={text} />; } } const Lazy = lazy(() => fakeImport(LazyImpl)); const instance1 = React.createRef(null); const instance2 = React.createRef(null); const root = ReactTestRenderer.create( <> <LazyImpl ref={instance1} label="Not lazy" /> <Suspense fallback={<Text text="Loading..." />}> <Lazy ref={instance2} label="Lazy" /> </Suspense> </>, { unstable_isConcurrent: true, }, ); expect(Scheduler).toFlushAndYield(['Not lazy: 0', 'Loading...']); expect(root).not.toMatchRenderedOutput('Not lazy: 0Lazy: 0'); await Promise.resolve(); expect(Scheduler).toFlushAndYield(['Lazy: 0']); expect(root).toMatchRenderedOutput('Not lazy: 0Lazy: 0'); // Should bailout due to shallow equal props and state instance1.current.setState({}); expect(Scheduler).toFlushAndYield([]); expect(root).toMatchRenderedOutput('Not lazy: 0Lazy: 0'); // Should bailout due to shallow equal props and state instance2.current.setState({}); expect(Scheduler).toFlushAndYield([]); expect(root).toMatchRenderedOutput('Not lazy: 0Lazy: 0'); }); </ins> it('sets defaultProps for modern lifecycles', async () => { class C extends React.Component { static defaultProps = {text: 'A'};


Question:
React version: 16.13.1 This code works fine when using plain , but fails: when is enabled: The warning is caused by an exception happened in this block: This is happening because module brings its own implementation of the object with slightly different behavior which requires context to be properly preserved. This one-line change should do the fix: This issue has also been reported to React-testing-library, which has similar code: Why should this be a fix in React and not in ESM? React relied on undocumented behavior of Node modules loader. It was never guaranteed that it will work without proper context. In fact, it will not work as expected if you try it with any non built-in module The current code in React may break in future if module will be replaced with anything else, or if changes their internal implementation.
Do you want to submit a PR It sounds like a reasonable thing for us to fix.
I could, however I am not sure about testing part. What kind of tests would you expect for this?

const nodeRequire = module && module[requireString]; // assuming we're in node, let's try to get node's // version of setImmediate, bypassing fake timers if any. <del> enqueueTaskImpl = nodeRequire('timers').setImmediate; </del> <ins> enqueueTaskImpl = nodeRequire.call(module, 'timers').setImmediate; </ins> } catch (_err) { // we're in a browser // we can't use regular timers because they may still be faked


return JSON.parse(raw); } } catch (error) {} <del> return true; </del> <ins> return false; </ins> } export function setBreakOnConsoleErrors(value: boolean): void {


Question:
Describe what you were doing when the bug occurred: on commits greater than 3s through the commits doing a next next Please do not remove the text below this line DevTools version: 4.10.1- Call stack: at updateTree (chrome-) at getCommitTree (chrome-) at ProfilingCacheProfilingCache.getCommitTree (chrome-) at CommitFlamegraphAutoSizer (chrome-) at Hh (chrome-) at qi (chrome-) at mk (chrome-) at lk (chrome-) at kk (chrome-) at ck (chrome-) Component stack: at CommitFlamegraphAutoSizer (chrome-) at div at div at div at SettingsModalContextController (chrome-) at ProfilerProfiler (chrome-) at ErrorBoundaryErrorBoundary (chrome-) at PortaledContent (chrome-) at div at div at ProfilerContextController (chrome-) at TreeContextController (chrome-) at SettingsContextController (chrome-) at ModalDialogContextController (chrome-) at DevToolsDevTools (chrome-)
Can you reliably reproduce this? If so, can you please share a repro case with us? (The bug is unlikely to be fixed without out.)
Should I be providing the profiler json? Because using a recording profiler json or the use case, I mentioned above, it reproduces always. Or are you looking for a repository where this can be reproduced?
Ah, sorry my original request was unclear. No, profiler JSON would likely just show that an element is indeed missing. A repro case (where I can run the code, see where/how/why DevTools misses the element) is what I need to fix.
Argh. So this is going to sound weird. I have a project where I can reproduce this, and I can do that always (see the date @ screenshot) but I can't ship it out due to a lot of internal tooling. So, I tried a similar use-case in my and I cannot it reproduce in that . I'll try some more and see if I can reproduce it in my personal project. The image below is from the project which I can't ship !
I would be willing to sign an NDA or similar agreement if that would help. Otherwise, it would be super helpful if you were able to reduce it to something that you could ship. (Maybe you could start with your full app and remove things until you get to the smallest case that repros the bug? Then you could share just that?)
Friendly ping. Any update or chance of one?
Hey try the below: Use this repo . The movie attached should help w/ repro steps. I also left some silly comments in - if you wanna try those out as well (somehow I feel they contribute to this trace - I could be wrong there). I haven't experimented much w/ the different yarn, node and npm versions, but below the ones which kinda did it. https://user-
Thank you for the repro! Holiday time so I might not take a look right away, but I'll try to look soonish.
I knew there will be so many edge cases for these unfound fiber errors Anyway, based on repro, the problem (for this case) is that there's a error thrown I think by the recursive function due to the big number of elements that it needs to mount. I reproduced it in . Here's the steps to reproduce it: profiling Show button Hide button profiling
That's good insight. Can confirm this on my side as well, (though only if I disable the host component filter). My intuition when writing DevTools was that it would be very uncommon for apps to have React trees deep or wide enough that the recursive function (or similar functions, e.g. ) would run out of stack. I think that's true, but given how large the user base is I guess it makes sense that it happens sometimes. I took a stab at rewriting the recursive methods in the backend/renderer in but didn't get them all (, , , ) because it would have been a big change and would make the code harder to read. Maybe worth picking back up and finishing that effort. Anyone interested? The good news is, DevTools has decent unit test coverage.
Hi I may not be able to start till next week, but I'd like to give it a shot if you're cool with it
Sounds great Keep me posted.
Friendly ping on this. Had the same issue multiple times and fallback to console log debugging
Circling back around to this. Using the excellent repro steps () shared by I can repro this faster if I change the default items (in ) from to . Then just loading the app, I notice the following error (in the console): If I ignore this error and profile anyway: the number of list items from 5,000 -0 several errors (in the DevTools extension console, likely caused by the stack overflow above): profiling an error now in DevTools UI (related to the previous errors): So the underlying cause here, as pointed out by is the original stack overflow error.
Converting all of the recursive methods in DevTools to be iterative would be a bit lift but I think I can fix this particular case by iterating over siblings rather than recursing. I'll post a PR shortly.

} function mountFiberRecursively( <del> fiber: Fiber, </del> <ins> firstChild: Fiber, </ins> parentFiber: Fiber | null, traverseSiblings: boolean, traceNearestHostComponentUpdate: boolean, ) { <del> if (__DEBUG__) { debug('mountFiberRecursively()', fiber, parentFiber); } </del> <ins> // Iterate over siblings rather than recursing. // This reduces the chance of stack overflow for wide trees (e.g. lists with many items). let fiber: Fiber | null = firstChild; while (fiber !== null) { if (__DEBUG__) { debug('mountFiberRecursively()', fiber, parentFiber); } </ins> <del> // If we have the tree selection from previous reload, try to match this Fiber. // Also remember whether to do the same for siblings. const mightSiblingsBeOnTrackedPath = updateTrackedPathStateBeforeMount( fiber, ); </del> <ins> // If we have the tree selection from previous reload, try to match this Fiber. // Also remember whether to do the same for siblings. const mightSiblingsBeOnTrackedPath = updateTrackedPathStateBeforeMount( fiber, ); </ins> <del> const shouldIncludeInTree = !shouldFilterFiber(fiber); if (shouldIncludeInTree) { recordMount(fiber, parentFiber); } </del> <ins> const shouldIncludeInTree = !shouldFilterFiber(fiber); if (shouldIncludeInTree) { recordMount(fiber, parentFiber); } </ins> <del> if (traceUpdatesEnabled) { if (traceNearestHostComponentUpdate) { const elementType = getElementTypeForFiber(fiber); // If an ancestor updated, we should mark the nearest host nodes for highlighting. if (elementType === ElementTypeHostComponent) { traceUpdatesForNodes.add(fiber.stateNode); traceNearestHostComponentUpdate = false; </del> <ins> if (traceUpdatesEnabled) { if (traceNearestHostComponentUpdate) { const elementType = getElementTypeForFiber(fiber); // If an ancestor updated, we should mark the nearest host nodes for highlighting. if (elementType === ElementTypeHostComponent) { traceUpdatesForNodes.add(fiber.stateNode); traceNearestHostComponentUpdate = false; } </ins> } <del> } // We intentionally do not re-enable the traceNearestHostComponentUpdate flag in this branch, // because we don't want to highlight every host node inside of a newly mounted subtree. } </del> <ins> // We intentionally do not re-enable the traceNearestHostComponentUpdate flag in this branch, // because we don't want to highlight every host node inside of a newly mounted subtree. } </ins> <del> const isSuspense = fiber.tag === ReactTypeOfWork.SuspenseComponent; if (isSuspense) { const isTimedOut = fiber.memoizedState !== null; if (isTimedOut) { // Special case: if Suspense mounts in a timed-out state, // get the fallback child from the inner fragment and mount // it as if it was our own child. Updates handle this too. const primaryChildFragment = fiber.child; const fallbackChildFragment = primaryChildFragment ? primaryChildFragment.sibling : null; const fallbackChild = fallbackChildFragment ? fallbackChildFragment.child : null; if (fallbackChild !== null) { mountFiberRecursively( fallbackChild, shouldIncludeInTree ? fiber : parentFiber, true, traceNearestHostComponentUpdate, ); </del> <ins> const isSuspense = fiber.tag === ReactTypeOfWork.SuspenseComponent; if (isSuspense) { const isTimedOut = fiber.memoizedState !== null; if (isTimedOut) { // Special case: if Suspense mounts in a timed-out state, // get the fallback child from the inner fragment and mount // it as if it was our own child. Updates handle this too. const primaryChildFragment = fiber.child; const fallbackChildFragment = primaryChildFragment ? primaryChildFragment.sibling : null; const fallbackChild = fallbackChildFragment ? fallbackChildFragment.child : null; if (fallbackChild !== null) { mountFiberRecursively( fallbackChild, shouldIncludeInTree ? fiber : parentFiber, true, traceNearestHostComponentUpdate, ); } } else { let primaryChild: Fiber | null = null; const areSuspenseChildrenConditionallyWrapped = OffscreenComponent === -1; if (areSuspenseChildrenConditionallyWrapped) { primaryChild = fiber.child; } else if (fiber.child !== null) { primaryChild = fiber.child.child; } if (primaryChild !== null) { mountFiberRecursively( primaryChild, shouldIncludeInTree ? fiber : parentFiber, true, traceNearestHostComponentUpdate, ); } </ins> } } else { <del> let primaryChild: Fiber | null = null; const areSuspenseChildrenConditionallyWrapped = OffscreenComponent === -1; if (areSuspenseChildrenConditionallyWrapped) { primaryChild = fiber.child; } else if (fiber.child !== null) { primaryChild = fiber.child.child; } if (primaryChild !== null) { </del> <ins> if (fiber.child !== null) { </ins> mountFiberRecursively( <del> primaryChild, </del> <ins> fiber.child, </ins> shouldIncludeInTree ? fiber : parentFiber, true, traceNearestHostComponentUpdate, ); } } <del> } else { if (fiber.child !== null) { mountFiberRecursively( fiber.child, shouldIncludeInTree ? fiber : parentFiber, true, traceNearestHostComponentUpdate, ); } } // We're exiting this Fiber now, and entering its siblings. // If we have selection to restore, we might need to re-activate tracking. updateTrackedPathStateAfterMount(mightSiblingsBeOnTrackedPath); </del> <ins> // We're exiting this Fiber now, and entering its siblings. // If we have selection to restore, we might need to re-activate tracking. updateTrackedPathStateAfterMount(mightSiblingsBeOnTrackedPath); </ins> <del> if (traverseSiblings && fiber.sibling !== null) { mountFiberRecursively( fiber.sibling, parentFiber, true, traceNearestHostComponentUpdate, ); </del> <ins> fiber = traverseSiblings ? fiber.sibling : null; </ins> } }


Question:
<!-- Please answer both questions below before submitting this issue. --Please provide a link to the URL of the website (if it is public), a CodeSandbox () example that reproduces the bug, or a project on GitHub that we can checkout and run locally. If possible, please describe how to reproduce this bug on the website or app mentioned above: <!-- FILL THIS IN --<!-- FILL THIS IN --<!-- FILL THIS IN --<!---------------------------------------------------<!-- Please do not remove the text below this line --<!---------------------------------------------------DevTools version: 4.13.1- Call stack: at chrome- at (chrome-) at chrome- at listener (chrome-) Component stack: (none) GitHub URL search query:
Hi I'm sorry you ran into this problem Unfortunately, it doesn't look like this issue has enough info for one of us to reproduce it though. This means that it's going to be very hard for us to fix. Please help us by providing a link to a CodeSandbox (), a repository on GitHub, or a minimal code example that reproduces the problem. (Screenshots or videos can also be helpful if they help provide context on how to repro the bug.) Here are some tips for providing a minimal example:
I am also having this bug
See the comment above please :) Repro is needed.
This happened to me, the node wasn't appearing in the Components tree and I was getting this error. The problem was that my attribute was way too long
! suddenly having this issue right now. I thought it was because of my commits, but changing to another old branch just give the same errors. it was working just fine yesterday, don't know why. maybe due to the devtools update or something? btw I'm on react 16.8.6, react devtools 4.13.3 (5/19/2021)
Try updating to the latest release (4.13.4) just to rule anything out. But if you're still seeing the issue, then we still need a repro case.
at first the bug still persists. with same error log. then I retried close the devtools and opened it again (I think I actually have done this as well before) then somehow it works now. the error log still shows up but at least now all components are showing on the devtools, and that's all I need. in addition, I found this ! and I was trying to hide that component (which has no recent changes on it) to see whether it has any impact. or any component that last showing on the devtools. but for now, that'll be all. thank you for responding
I appreciate the extra information, but this isn't a description that I can use to reproduce (and fix) the bug. I need an actual website (or code) that I can run along with instructions (like "do this, then this") so I can see the bug.
There are some simple code could help reproduce. You could try following code sandbox link. The reproduce steps are: "Do not" open develop panel. to develop panel and go to react dev tab. Errors was shown. I guess it's kind of race condition. When I change the component order such as It will work perfect. Ps: brief explain what component do. The PageLoadProgressHandler will dispatch float element to PopupPool.
Excellent! Thank you, Super interesting that this bug only occurs if you wait to open DevTools until after the page has loaded.
I think it is because only have two components, I have two sites, one it will always happen, another will random happen. or maybe code-sandbox do some strange things.
This is interesting. The reason DevTools throws is that the Fiber's owner (the attribute) points to a Fiber that hasn't been mounted yet. That seems unexpected. This repro is just a wrapper around two NPM packages. Where's the source code for these packages? :D Edit I found it, although there's a lot of indirection here_. Tracing one package which imports another which imports another. Would be helpful if it were flattened but I guess I can always step through the bundled source.
PopupPool: PageLoadProgressHandler: Good luck... XD.
Interestingly, if I copy the , , and source files into the sandbox (and only change the import statement in ) the bug goes away. That's surprising.
I wonder if I'm running slightly different code? The debug log shows a slightly different tree structure. Is the version of the source you linked me to the same as the one the Sandbox points to in NPM, Edit Looks like the repro is using 0.18.8 (released a couple of months ago) but the latest NPM release is 0.11.1. That being said, it doesn't look like the files that are being imported have changed (at least not in source) so I'm still not sure what's up.
I change two main components to hook style then get better performance, it reduce the error happen, but I still could get error. Some error is happen after component render done and open the panel same behavior with pervious. I'll log my changes in following issue ticket.
Would be nice to get a smaller reproduction of this issue (all of the code in one project, rather than spread across many NPM packages). That's what I was trying to do with moving the source but then the bug goes away b'c the code seems to be different. I noticed one potential difference being the indirection but I'm not sure how likely that is to be related.
Looking at the error while debugging, it looks like the , then either renders it or dispatches a popup event to show it. I'm not sure why (too sleepy to think it through maybe) but sometimes seems to be mounting before_ has, which goes against an assumption in DevTools. Will dig back in tomorrow.
I really appreciate the repro case, but there are so many layers of indirection between the various NPM packages being used to dynamically create the components. It's difficult to trace through. I'm going to hand this issue to you and ask for a smaller repro case. (Without 10+ NPM projects that each require each other.) Is this something you can help with? Edit I fixed this () but the test case I is not great since it relies on unsupported side effects to trigger the problem case. I'd still love to get a smaller repro so I can (1) be sure I fully fixed the problem and (2) add a regression case so it doesn't get re-introduced.
Bugfix released as
thank you fixed on version 4.13.5
Thanks your effort. Your fixed also be success from my side.

expect(store).toMatchSnapshot('2: add host nodes'); }); <ins> // This test is not the same cause as what's reported on GitHub, // but the resulting behavior (owner mounting after descendant) is the same. // Thec ase below is admittedly contrived and relies on side effects. // I'mnot yet sure of how to reduce the GitHub reported production case to a test though. // See https://github.com/facebook/react/issues/21445 it('should handle when a component mounts before its owner', () => { const promise = new Promise(resolve => {}); let Dynamic = null; const Owner = () => { Dynamic = <Child />; throw promise; }; const Parent = () => { return Dynamic; }; const Child = () => null; const container = document.createElement('div'); act(() => ReactDOM.render( <> <React.Suspense fallback="Loading..."> <Owner /> </React.Suspense> <Parent /> </>, container, ), ); expect(store).toMatchInlineSnapshot(` [root] <Suspense> ▾ <Parent> <Child> `); }); </ins> describe('collapseNodesByDefault:false', () => { beforeEach(() => { store.collapseNodesByDefault = false;


Question:
<!-- Please answer both questions below before submitting this issue. --Please provide a link to the URL of the website (if it is public), a CodeSandbox () example that reproduces the bug, or a project on GitHub that we can checkout and run locally. If possible, please describe how to reproduce this bug on the website or app mentioned above: <!-- FILL THIS IN --<!-- FILL THIS IN --<!-- FILL THIS IN --<!---------------------------------------------------<!-- Please do not remove the text below this line --<!---------------------------------------------------DevTools version: 4.13.1- Call stack: at chrome- at (chrome-) at chrome- at listener (chrome-) Component stack: (none) GitHub URL search query:
Hi I'm sorry you ran into this problem Unfortunately, it doesn't look like this issue has enough info for one of us to reproduce it though. This means that it's going to be very hard for us to fix. Please help us by providing a link to a CodeSandbox (), a repository on GitHub, or a minimal code example that reproduces the problem. (Screenshots or videos can also be helpful if they help provide context on how to repro the bug.) Here are some tips for providing a minimal example:
I am also having this bug
See the comment above please :) Repro is needed.
This happened to me, the node wasn't appearing in the Components tree and I was getting this error. The problem was that my attribute was way too long
! suddenly having this issue right now. I thought it was because of my commits, but changing to another old branch just give the same errors. it was working just fine yesterday, don't know why. maybe due to the devtools update or something? btw I'm on react 16.8.6, react devtools 4.13.3 (5/19/2021)
Try updating to the latest release (4.13.4) just to rule anything out. But if you're still seeing the issue, then we still need a repro case.
at first the bug still persists. with same error log. then I retried close the devtools and opened it again (I think I actually have done this as well before) then somehow it works now. the error log still shows up but at least now all components are showing on the devtools, and that's all I need. in addition, I found this ! and I was trying to hide that component (which has no recent changes on it) to see whether it has any impact. or any component that last showing on the devtools. but for now, that'll be all. thank you for responding
I appreciate the extra information, but this isn't a description that I can use to reproduce (and fix) the bug. I need an actual website (or code) that I can run along with instructions (like "do this, then this") so I can see the bug.
There are some simple code could help reproduce. You could try following code sandbox link. The reproduce steps are: "Do not" open develop panel. to develop panel and go to react dev tab. Errors was shown. I guess it's kind of race condition. When I change the component order such as It will work perfect. Ps: brief explain what component do. The PageLoadProgressHandler will dispatch float element to PopupPool.
Excellent! Thank you, Super interesting that this bug only occurs if you wait to open DevTools until after the page has loaded.
I think it is because only have two components, I have two sites, one it will always happen, another will random happen. or maybe code-sandbox do some strange things.
This is interesting. The reason DevTools throws is that the Fiber's owner (the attribute) points to a Fiber that hasn't been mounted yet. That seems unexpected. This repro is just a wrapper around two NPM packages. Where's the source code for these packages? :D Edit I found it, although there's a lot of indirection here_. Tracing one package which imports another which imports another. Would be helpful if it were flattened but I guess I can always step through the bundled source.
PopupPool: PageLoadProgressHandler: Good luck... XD.
Interestingly, if I copy the , , and source files into the sandbox (and only change the import statement in ) the bug goes away. That's surprising.
I wonder if I'm running slightly different code? The debug log shows a slightly different tree structure. Is the version of the source you linked me to the same as the one the Sandbox points to in NPM, Edit Looks like the repro is using 0.18.8 (released a couple of months ago) but the latest NPM release is 0.11.1. That being said, it doesn't look like the files that are being imported have changed (at least not in source) so I'm still not sure what's up.
I change two main components to hook style then get better performance, it reduce the error happen, but I still could get error. Some error is happen after component render done and open the panel same behavior with pervious. I'll log my changes in following issue ticket.
Would be nice to get a smaller reproduction of this issue (all of the code in one project, rather than spread across many NPM packages). That's what I was trying to do with moving the source but then the bug goes away b'c the code seems to be different. I noticed one potential difference being the indirection but I'm not sure how likely that is to be related.
Looking at the error while debugging, it looks like the , then either renders it or dispatches a popup event to show it. I'm not sure why (too sleepy to think it through maybe) but sometimes seems to be mounting before_ has, which goes against an assumption in DevTools. Will dig back in tomorrow.
I really appreciate the repro case, but there are so many layers of indirection between the various NPM packages being used to dynamically create the components. It's difficult to trace through. I'm going to hand this issue to you and ask for a smaller repro case. (Without 10+ NPM projects that each require each other.) Is this something you can help with? Edit I fixed this () but the test case I is not great since it relies on unsupported side effects to trigger the problem case. I'd still love to get a smaller repro so I can (1) be sure I fully fixed the problem and (2) add a regression case so it doesn't get re-introduced.
Bugfix released as
thank you fixed on version 4.13.5
Thanks your effort. Your fixed also be success from my side.

const elementType = getElementTypeForFiber(fiber); const {_debugOwner} = fiber; <del> const ownerID = _debugOwner != null ? getFiberIDThrows(_debugOwner) : 0; </del> <ins> // Ideally we should call getFiberIDThrows() for _debugOwner, // since owners are almost always higher in the tree (and so have already been processed), // but in some (rare) instances reported in open source, a descendant mounts before an owner. // Since this is a DEV only field it's probably okay to also just lazily generate and ID here if needed. // See https://github.com/facebook/react/issues/21445 const ownerID = _debugOwner != null ? getOrGenerateFiberID(_debugOwner) : 0; </ins> const parentID = parentFiber ? getFiberIDThrows(parentFiber) : 0; const displayNameStringID = getStringID(displayName);


Question:
DevTools named hook parsing logic currently matches AST nodes using the original line number: But this may not be sufficient, as mentioned in comment
While we're on the subject: Column numbers in particular are where a lot of inconsistencies between tools/engines' representations occur and off-by-one errors creep in. V8, SpiderMonkey, JSC all use 1-based lines and 1-based columns in . Hermes follows the other engines for the most part but has its own thing going on for bytecode addresses (printed similarly to columns but 0-based). See the in React Native. VS Code uses 1-based lines and 1-based columns. The library (at least AFAIK from older versions) uses 1-based lines and 0-based columns in its API. ESTree/Babel ASTs use 1-based lines and 0-based columns. The Chrome DevTools protocol uses 0-based lines and 0-based columns. So I suspect we have an incorrect conversion already - we should fix it and signpost assumptions/conversions more clearly.
Reopening to address this follow up comment from

return false; } <ins> // Column numbers are representated differently between tools/engines. // Error.prototype.stack columns are 1-based (like most IDEs) but ASTs are 0-based. // // In practice this will probably never matter, // because this code matches the 1-based Error stack location for the hook Identifier (e.g. useState) // with the larger 0-based VariableDeclarator (e.g. [foo, setFoo] = useState()) // so the ranges should always overlap. // // For more info see https://github.com/facebook/react/pull/21833#discussion_r666831276 column -= 1; </ins> if ( (line === start.line && column < start.column) || (line === end.line && column > end.column)


Question:
DevTools named hook parsing logic currently matches AST nodes using the original line number: But this may not be sufficient, as mentioned in comment
While we're on the subject: Column numbers in particular are where a lot of inconsistencies between tools/engines' representations occur and off-by-one errors creep in. V8, SpiderMonkey, JSC all use 1-based lines and 1-based columns in . Hermes follows the other engines for the most part but has its own thing going on for bytecode addresses (printed similarly to columns but 0-based). See the in React Native. VS Code uses 1-based lines and 1-based columns. The library (at least AFAIK from older versions) uses 1-based lines and 0-based columns in its API. ESTree/Babel ASTs use 1-based lines and 0-based columns. The Chrome DevTools protocol uses 0-based lines and 0-based columns. So I suspect we have an incorrect conversion already - we should fix it and signpost assumptions/conversions more clearly.
Reopening to address this follow up comment from

line: lineNumber, // Column numbers are representated differently between tools/engines. <ins> // Error.prototype.stack columns are 1-based (like most IDEs) but ASTs are 0-based. </ins> // For more info see https://github.com/facebook/react/issues/21792#issuecomment-873171991 column: columnNumber - 1, });


Question:
Currently the CHANGELOG shows 4.3.0 as the latest version of , but at least on , there is not a 4.4.0. React version: n/a Changelog to version on Link to code example: n/a No 4.4.0 explanation in 0 explanation in
I think 4.4.0 was essentially a no-op release to correspond with React 18 release (though cc to confirm). Looking at what's changed in the package between the 4.3.0 release and Monday's 4.4.0 "release" I see: I believe this is the same thing as happened with the ESLint 4.2.0 release and React 17. I believe the "fix" here would be to just add a 4.4.0 release to the CHANGELOG that notes this.
Thanks so much That definitely seems like the right fix!

<ins> ## 4.4.0 * No changes, this was an automated release together with React 18. </ins> ## 4.3.0 * Support ESLint 8. ([@MichaelDeBoey](https://github.com/MichaelDeBoey) in [#22248](https://github.com/facebook/react/pull/22248))


Question:
<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: main branch "" in " and its " <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --The page is 404. The page should exist.
Fixed by

The examples in the React repository are declared a bit differently than a third-party renderer would be. In particular, the `HostConfig` object mentioned above is never explicitly declared, and instead is a *module* in our code. However, its exports correspond directly to properties on a `HostConfig` object you'd need to declare in your code: * [React ART](https://github.com/facebook/react/blob/main/packages/react-art/src/ReactART.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-art/src/ReactARTHostConfig.js) <del> * [React DOM](https://github.com/facebook/react/blob/main/packages/react-dom/src/client/ReactDOM.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-dom/src/client/ReactDOMHostConfig.js) </del> <ins> * [React DOM](https://github.com/facebook/react/blob/main/packages/react-dom/src/client/ReactDOM.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-dom-bindings/src/client/ReactDOMHostConfig.js) </ins> * [React Native](https://github.com/facebook/react/blob/main/packages/react-native-renderer/src/ReactNativeRenderer.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-native-renderer/src/ReactNativeHostConfig.js) If these links break please file an issue and we’ll fix them. They intentionally link to the latest versions since the API is still evolving. If you have more questions please file an issue and we’ll try to help!


Question:
Can't send ArrayBuffer to Server Action despite saying that you can. I'm not sure if this is an error or my part or the documentation. I retrieved the arrayBuffer from file of formData, then pass it through the parameter of the Server Action. It seems like it doesn't get sent to the server because it can't be parsed due to ArrayBuffer being serializable but not iterable. However this is somewhat confusing because you can attach File in FormData in the form of Blob and send it to the Server Action. I understand that FormData is but I'm not sure I understand why it can't be done the same with ArrayBuffer. I understand that I can just pass the FormData to send files but In my case I needed to transform the Files first before uploading and it ends up with a Blob. <!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: form, input, submit button, and also onSubmit function using Client Action the arrayData from the formData then pass it to server action <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: -- Throws client-side error ArrayBuffer gets sent to the server The documentation: <img width="583" alt="image" src=""Please let me know if I fail to understand the documentation or if it's something wrong in the documentation
I'm having the same issue.
Wokraround: I've tested multiple react/nextjs version combinations and now found working one. For me it's nextjs 13.5.6 and react 18.2.0. Reply pls when you try it out)
I will test. I'm using and
The workaround i have for now is to wrap the data with FormData first and append the file before sending it to the server action
It seems that shipping as parameters of the server action is enabled, but returning from the server action is still not enabled.
as per the documentation, that is the intended behavior
They're supported as return values in Server Actions in React's Experimental release channel. Sending to Server Actions is currently not supported but we want to achieve parity eventually. I'll file a PR updating the docs accordingly.
Will be supported by
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!

<del> /** * Copyright (c) 2015-present, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @providesModule ReactNativeGlobalInteractionHandler * @flow */ 'use strict'; var InteractionManager = require('InteractionManager'); // Interaction handle is created/cleared when responder is granted or // released/terminated. var interactionHandle = null; var ReactNativeGlobalInteractionHandler = { onChange: function(numberActiveTouches: number) { if (numberActiveTouches === 0) { if (interactionHandle) { InteractionManager.clearInteractionHandle(interactionHandle); interactionHandle = null; } } else if (!interactionHandle) { interactionHandle = InteractionManager.createInteractionHandle(); } }, }; module.exports = ReactNativeGlobalInteractionHandler; </del>