jiebi/CodeConvo huggingface dataset:
Code change:
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);

Related discussion:
text: <!-- 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.
Code change:
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);

Related discussion:
text: 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.
Code change:
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);

Related discussion:
text: 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.
Code change:
: emptyObject; const instance = new ctor(props, context); adoptClassInstance(workInProgress, instance); <del> checkClassInstance(workInProgress); </del> // Cache unmasked context so we can avoid recreating masked context unless necessary. // ReactFiberContext usually updates this cache but can't for newly-created instances.

Related discussion:
text: Follow up from Here's one I found. These two invariants: are in a function that's behind a DEV block: I don't think this is intentional, but need to verify. There may be more. I'll use this issue to track while preserves existing behavior.
Here’s another difference: in development, putting a string ref on a functional component throws with: Stateless function components cannot have refs. but in production gives you: Element ref was specified as a string but no owner was set.
Code change:
that support `*.tmLanguage`. * Linting provides accurate line numbers after compiling without sourcemaps. * Elements use standard scoping so linters can find usage of out-of-scope components. <ins> ### Debugging [React Developer Tools](https://github.com/facebook/react-devtools) is a [Chrome extension](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en) that allows you to inspect the React component hierarchy in the Chrome Developer Tools. </ins>

Related discussion:
text: I don't know where the right place to link to them is. Maybe "Getting started", "Tutorial" and "Tooling integration"?
Code change:
} export function createLaneMap<T>(initial: T): LaneMap<T> { <del> return new Array(TotalLanes).fill(initial); </del> <ins> // Intentionally pushing one by one. // https://v8.dev/blog/elements-kinds#avoid-creating-holes const laneMap = []; for (let i = 0; i < TotalLanes; i++) { laneMap.push(initial); } return laneMap; </ins> } export function markRootUpdated(

Related discussion:
text: After updating react-dom to version 17 the build now includes () which isn't supported by ie11 without polyfilling. Coming from this line. Tested with just the default cra production build to make sure it wasn't a problem with my webpack config and the same issue. Tested using CRA on version 16.9.8 of react and react-dom which works with the production build for ie11.
Confirmed with https://csb-hznfc- (built from ) which errors with "SCRIPT438: Object doesn't support property or method 'fill'".
Any chance you could confirm the fix on a real IE
Gonna wait to see if a few more bugs get reported in the next few hours. Then will cut a patch.
Should be fixed in 17.0.1.
Code change:
echo "Only docs were updated, stopping build process." exit fi <del> npm install -g npm </del> <ins> npm install -g npm@latest-2 </ins> script: - | if [ "$TEST_TYPE" = build_website ]; then

Related discussion:
text: Since upgrading from beta3 to rc1 I've seen this error a few times in production. Haven't been able to trace the source yet though. cc
I was unmounting a root during a keyboard event which caused this to happen. I think this has always been a problem? Perhaps we've only been lucky... leaving open just to be sure. EDIT: Could it make sense to have something along the lines of ? Allowing you to schedule things to occur as soon as the current transaction ends.
This invariant was new in this release. We also hit one case at FB that I haven't yet investigated. Probably need to change something for the final release.
I have seen this on RC1 can't find a sequence of actions to repeat it.
I'm running into this issue as well when conditionally rendering based on state. Not sure how to boil it down to a simple reproducible bug report yet.
My issue only happens when I am leveraging FastClick. Didn't happen before 0.14.
I've found it is because the events are handled in a different order with fastclick, so the batching gets weird...
e.g. click gets fired before touchEnd, so click handler setState to remove subtree, and then react tries to do something with it in touch end perhaps?
Code change:
echo "Only docs were updated, stopping build process." exit fi <del> npm install -g npm </del> <ins> npm install -g npm@latest-2 </ins> script: - | if [ "$TEST_TYPE" = build_website ]; then

Related discussion:
text: In this repro, I created 2 buttons and only one is rendered at a time. One button's click handler is hooked up to React's synthetic "click" event while the other is hooked up to the native "click" event. Even though only one button is rendered at a time, a single click is triggering both click events. This bug can be hit by apps that mix React components with non-React controls (e.g. jQuery UI). I reproed this in Chrome with React 0.13.2. to the button labeled "One" Expected: There's a button rendered labeled "Two" Actual: The rendered button still has the label "One" If you open the console, you'll see "goToTwo" and "goToOne" which indicates that the "One" button's click handler ran and then the "Two" button's click handler ran (even though we never saw button "Two"").
I experimented more and came up with another repro: In this one, you click on a button with a native "click" handler which causes the button to go away and an input field to be rendered. It results in this exception: From these 2 repros, it seems something strange is going on when calling from within a native "click" handler.
It works if you add to the event handler.
Thanks for the workaround. Is the behavior without the by design? It looks like the bad behavior is being caused by the rerender happening synchronously within the native "click" handler.
This looks bad. We don't do a great job interacting with native events. Sebastian wrote a post about this once-upon-a-time, how native and synthetic event systems are, by and large, not interoperable. Even so, I can't see a reason we should fatal like this. Do you understand what's going wrong here? What a fix might look like?
This happens when we handle a click event from a node that's been removed in between when the event is triggered and when React receives it. How should we deal with the case that events fire on detached elements? Should we ignore events for nodes that aren't in the document? I don't think the bug is easily fixable otherwise because we don't have the old event handler after the reconcile that removes that node.
Here are some additional details about the impact of the bug.
Code change:
echo "Only docs were updated, stopping build process." exit fi <del> npm install -g npm </del> <ins> npm install -g npm@latest-2 </ins> script: - | if [ "$TEST_TYPE" = build_website ]; then

Related discussion:
text: It sounds like this bug is likely to trigger when you use a non-React component (e.g. jQuery UI) in a React single page application and the non-React component triggers a navigation within the app.
Thanks for an excellent bug report and good repro case! I think this happens because we use the "root id" to determine which element was clicked. In the repro case there is no "key" as part of the root ID for two reasons: 1) It is not a child of a container (multichild) so it doesn't get a key to the root ID. 2) It doesn't have a unique key and doesn't need one because it the button is of a different type. If I make sure that a key is used as part of the root ID the problem is solved: So the problem in the repro isn't that we're firing on a removed node, it is that we're firing the event on the new node. This would be solved if we used a unique ID per instance to identify event handlers instead of a generate root that is non-unique. Which I think we wanted to do anyway. Is there another repro that shows a different issue?
Code change:
var Component = this._currentElement.type; // Initialize the public class <del> var inst; </del> <ins> var inst = this._constructComponent(publicProps, publicContext); </ins> var renderedElement; <del> if (Component.prototype && Component.prototype.isReactComponent) { if (__DEV__) { ReactCurrentOwner.current = this; try { inst = new Component(publicProps, publicContext, ReactUpdateQueue); } finally { ReactCurrentOwner.current = null; } } else { inst = new Component(publicProps, publicContext, ReactUpdateQueue); } } else { if (__DEV__) { ReactCurrentOwner.current = this; try { inst = Component(publicProps, publicContext, ReactUpdateQueue); } finally { ReactCurrentOwner.current = null; } } else { inst = Component(publicProps, publicContext, ReactUpdateQueue); } if (inst == null || inst.render == null) { renderedElement = inst; warnIfInvalidElement(Component, renderedElement); invariant( inst === null || inst === false || ReactElement.isValidElement(inst), '%s(...): A valid React element (or null) must be returned. You may have ' + 'returned undefined, an array or some other invalid object.', Component.displayName || Component.name || 'Component' ); inst = new StatelessComponent(Component); } </del> <ins> // Support functional components if (!shouldConstruct(Component) && (inst == null || inst.render == null)) { renderedElement = inst; warnIfInvalidElement(Component, renderedElement); invariant( inst === null || inst === false || ReactElement.isValidElement(inst), '%s(...): A valid React element (or null) must be returned. You may have ' + 'returned undefined, an array or some other invalid object.', Component.displayName || Component.name || 'Component' ); inst = new StatelessComponent(Component); </ins> } if (__DEV__) {

Related discussion:
text: There appears to have been a change in how is generated between 0.13 and 0.14 which is causing a number of our shallow rendered tests to fail when upgrading because the deepEquals fails on the property. Here is a simple example component which exhibits the issue.
I've been seeing some similar issues with shallow rendering. My current (messy - sorry!) workaround is this: Let me know if that helps! My version currently breaks some of the Jest tests, but I'm happy to work on this some more and submit a PR.
Thank you very much for this, it's been a tremendous help! While this solved the problem for my test case above it still failed on a large number of our more complex tests. I've been iterating on it and once I have all of our tests passing I'll add the updated version.
Here is the updated workaround, it works for our 238 tests of varying complexity but I'd be interested to see if it passes all of your tests as well.
Awesome! If you don't mind trying, what happens if you do and then use the earlier ?
Much cleaner thanks, I guess I was in my head too much :)
I prefer applying a monkey patch, until we have this fixed in react by wrapping TestUtils in my own module:
This should be fixed by .
Code change:
items: - id: flux-overview title: Flux Overview <ins> href: http://facebook.github.io/flux/docs/overview.html </ins> - id: flux-todo-list title: Flux TodoMVC Tutorial <ins> href: http://facebook.github.io/flux/docs/todo-list.html </ins>

Related discussion:
text: We're basically keeping 2 copies of documentation in sync and failing. We should just point at and We should maybe make the permalinks on our site redirect or just link offsite. We should also look for links in our docs pointing to those pages and update.
cc
also cc
Definitively agreed, we should link all the traffic to the dedicated website. See the Complementary section on Flux website
Code change:
const Resolved = 2; const Rejected = 3; <del> type EmptyRecord<K, V> = {| </del> <ins> type EmptyRecord<K> = {| </ins> status: 0, suspender: null, key: K, value: null, error: null, <del> next: Record<K, V> | null, previous: Record<K, V> | null, </del> <ins> next: any, // TODO: (issue #12941) previous: any, // TODO: (issue #12941) /** * Proper types would be something like this: * next: Record<K, V> | null, * previous: Record<K, V> | null, */ </ins> |}; type PendingRecord<K, V> = {| status: 1, <del> suspender: Promise<K, V>, </del> <ins> suspender: Promise<V>, </ins> key: K, value: null, error: null, <del> next: Record<K, V> | null, previous: Record<K, V> | null, </del> <ins> next: any, // TODO: (issue #12941) previous: any, // TODO: (issue #12941) /** * Proper types would be something like this: * next: Record<K, V> | null, * previous: Record<K, V> | null, */ </ins> |}; type ResolvedRecord<K, V> = {|

Related discussion:
text: In we landed a change to the Flow types in , making the types for the various types recursive with their and properties. On that PR we may have been running an older version of Flow - I'm not having luck finding the record of when Flow ran for that PR, so not sure. In any case, that PR was merged even though it had the recursive Flow type definitions, plus one or more Flow errors which were unrelated and not detected. The problem with the recursive type definitions is that recent versions of Flow will go into an infinite loop if they try to infer types which are recursive. The solution may be to add more detail to those types, but to unblock things we temporarily made them looser type definitions.
Code change:
export const enableSelectiveHydration = false; export const enableChunksAPI = false; export const exposeConcurrentModeAPIs = __EXPERIMENTAL__; <del> export const warnAboutShorthandPropertyCollision = false; </del> <ins> export const warnAboutShorthandPropertyCollision = true; </ins> export const enableSchedulerDebugging = false; export const debugRenderPhaseSideEffectsForStrictMode = true; export const disableJavaScriptURLs = false;

Related discussion:
text: I a "bug" today that made me spent 1h figuring out what was going on: I'm using an external component that accepts a prop in order to set the of the root element, but this same component also accepts a prop which I wasn't passing, and by default, it was set to . The result: React didn't throw an error nor a warning, however, the resulting element in the DOM didn't contain either or , and since the element had a default coming from a CSS class, it took me a while to figure out why the color that I was passing wasn't being applied, and instead it was using the one from the CSS class. See: What I reported above was the case. I other cases as a bonus, as when I was playing with this they also seemed weird to me. On I define the same properties, but because I change the order, it works. On the toggleable ones, initially I can see the background, but after changing it never appears anymore. I'm not sure if I created those extra "test cases" correctly. My main concern is really around static1 not outputting anything on the console as a warning. Related issues: I wonder if ( should have covered this?
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!
it seems that the bot automatically closed the issue, but this still needs action. I took a time to investigate it, and I realized that the work Sophie has done covers this case, but there's just one problem: it's disabled under a . I built it locally and flipped the flag, and it works: I can see the helpful warning. It was flagged in , and as per the PR, the original intention was to unflag it on the next minor. Since then we had at least 4 new minor versions, but it is still flagged. Is there a special reason for that or was it just forgotten? tagging you since you this flag, so I'm hoping you can give context here.
Can we unflag this?
This was released.