jiebi/CodeConvo huggingface dataset:
Change:
); }); <del> it('should properly log warnings when events simulated with rendered components', function() { </del> <ins> // TODO: reenable this test. We are currently silencing these warnings when // using TestUtils.Simulate to avoid spurious warnings that result from the // way we simulate events. xit('should properly log warnings when events simulated with rendered components', function() { </ins> spyOn(console, 'error'); var event; var element = document.createElement('div');

Discussion:
To reproduce, open Error is logged to browser dev tools (in Chrome & Firefox, somehow not in Safari). Happens on v15.0.0-rc.2 and on latest master version. The assignment of additional event data to the newly created SyntheticEvent triggers a console error:
Thanks for reporting. We'll get this fixed.
Are we not checking for unexpected warnings in tests? Should we? Curious how this crept in unnoticed.
node doesn't support Proxies so none of that code is actually getting tested :/ Even running with flag (which we do at least with ) doesn't enable it since it's "in progress". We could probably run with to force it on.
Change:
if (__DEV__) { warning( <del> typeof shouldUpdate !== 'undefined', </del> <ins> shouldUpdate !== undefined, </ins> '%s.shouldComponentUpdate(): Returned undefined instead of a ' + 'boolean value. Make sure to return true or false.', this.getName() || 'ReactCompositeComponent'

Discussion:
Introduction I found a bug on resolving default props when component props have property with HTMLAllCollection. React ignores value and uses default value (it should take that collection). isIE9OrLower (look at the end of topic) is simple function to test Internet Explorer in version 9 or lower. Simple use case: Chrome/Firefox/modern IE (yeah, i know....) returns HTMLAllColection (as ), but old IE returns true. HTMLAllCollection is weird collection: Source of bug and fix release: 0.14.7 file: line: 9149 code (bug): if (typeof props[propName] === 'undefined') { code (fix): if (props[propName] === undefined) { Btw, === undefined is faster than typeof === 'undefined' on Chrome and IE. Reproduction Open in Firefox / Chrome / IE10 or higher. Fiddle: Raw: Workaround Change to
Haha, browsers suck. Want to submit a PR? It looks like we do that thing unnecessarily in a few places in the React codebase. Note that we do need to use typeof if the binding might not exist, so we need to look at each case individually to make sure the change is valid there.
I went through the react repo configuration (build, tests execution). Fix didn't break anything, but so far I didn't find solution to make good test (phantomjs doesn't have property). (HTMLAllCollection) is probably the only exception to the typeof and is not a html standard. Any suggestions to the unit test for this fix/improvement?
As long as you tested it manually and it worked in IE, I think we can accept this change without a unit test.
Fixed in
lol what even
I can't reproduce being in IE 8 or IE 9 on Windows 7, either in standards or quirks mode. What am I missing?
IE < 10 is fine. Problem occurs when using modern browser like Chrome, Firefox, IE = 10 or Edge. They returns . component prop as in Chrome. will compare your prop with default prop (which is ). on Chrome is so React treats it as missing value. Default prop () will be selected. the end, prop will be always set to on modern browser in this case.
Oh! Sorry I totally misread. Yes I can repro this.
Change:
} this.state = this.getInitialState ? this.getInitialState() : null; <ins> invariant( typeof this.state === 'object' && !Array.isArray(this.state), '%s.getInitialState(): must return an object or null', this.constructor.displayName || 'ReactCompositeComponent' ); </ins> this._pendingState = null; this._pendingForceUpdate = false;

Discussion:
See Return a string from and call . You get this amazing error message:
We should probably add an that whatever is returned from is in fact an object.
Invariant all the things :)
This also seems to apply when using an array, not the string only. Which makes it a pretty real-world bug IMHO (compared to the weird string scenario). Or is there a reason you don't want states to be arrays?
This will happen whenever state is anything but an Object (I think there is a check in there for arrays). Since we use merge it needs to be an object, arrays are no good either.
Change:
); } }); <ins> JQueryMobileHeader = React.createFactory(JQueryMobileHeader); </ins> /** jQuery Mobile page component. */ var JQueryMobilePage = React.createClass({

Discussion:
When I run the in examples jquery-mobile in the chromium browser, I get: Uncaught TypeError: Cannot read property '__reactAutoBindMap' of (anonymous function)
I can confirm. Works fine with React version “0.12.2", but "0.13.0-alpha.2" gives: Uncaught TypeError: Cannot read property '__reactAutoBindMap' of undefined ReactClass.createClass.Constructor (anonymous function) The jquery-mobile example is using component constructors in a way which makes the new version explode. gaearon lays is out here:
We'll make sure all the examples are working before we release 0.13 final but until then there's a non-trivial change they'll be broken at any point in time. Check out the latest stable branch for the working examples.
Change:
return; } if (propTypes) { <ins> // Intentionally inside to avoid triggering lazy initializers: const name = getComponentName(type); </ins> checkPropTypes(propTypes, element.props, 'prop', name, element); } else if (type.PropTypes !== undefined && !propTypesMisspellWarningShown) { propTypesMisspellWarningShown = true; <ins> // Intentionally inside to avoid triggering lazy initializers: const name = getComponentName(type); </ins> console.error( 'Component %s declared `PropTypes` instead of `propTypes`. Did you misspell the property assignment?', name || 'Unknown',

Discussion:
<!-- 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: 17.0.0-rc.1 elements out of components, use them conditionally. if the components are dynamically imported. <!-- 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: --The chunk is imported eagerly, even though the component isn't immediately rendered. ! This doesn't happen in prod mode, or with React 16, or with components that are not -ed eagerly. This affects react-router, as it uses this pattern: AFAICT it doesn't break anything, but it is unexpected/confusing. components that are not rendered should not be dynamically imported.
Shorter test case: This is enough to trigger the dynamic import in dev mode.
Behavior changed between 16.13.1 and the first release after . ! !
This is triggered by in . I think this doesn't really make sense to call but we'd need to see why this change to was made. <img width="398" alt="Screenshot 2020-09-03 at 13 56 14" src="https://user-"<img width="367" alt="Screenshot 2020-09-03 at 13 56 18" src="https://user-"
The suspense protocol is just a function that may throw. That allows for low overhead abstractions to be wrapped. This change was to allow the init function to encapsulate the actual suspense mechanism and that data structure. Unfortunately there’s no way to query the status of something in the suspense protocol without triggering the fetch. Same as you can’t do: Without triggering a fetch. The solution might be to move validation of lazy until it’s rendered instead of in createElement. Also, sigh PropTypes.

Should the label be removed?
Should be fixed in . Please verify.
Works great now, thanks! Looking forward to the 17.0.0 release.
Change:
return JSON.parse(raw); } } catch (error) {} <del> return true; </del> <ins> return false; </ins> } export function setBreakOnConsoleErrors(value: boolean): void {

Discussion:
<!-- 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. --Looks like you forgot about the debugger inside the React dev tools version: 4.8.0 (or install) the latest version of devtools devtools code will be stopped on the debugger inside ! If I open devtools with react dev tools extension it will stop every time on debugger inside It doesn't seem like it should be happening
Same here, I've had to disable the extension because of this... :smile:
Same for me.
Looks bad.
Same here
That's the guy you're looking for :D
Yes, but see the comment above it. :-) It is intentional, but this option should have been off by default.
As a temporary solution you can "blackbox" script in Chrome Dev Tools: !
You should also be able to go to Components tab, press Settings gear, add checkbox to Break on Warning, then do this again, and remove the checkbox as a temporary workaround.
I'll keep it open until we cut a release
Thanks
I've submitted a fix to Chrome addons. It should appear there in a few hours. If it doesn't work after updating to 4.8.1, try to clear your local storage (). I can't figure out how to submit it to FF store because something in our process has changed. So will be able to help us out there when he wakes up.

:-)
Here's a step-by-step instruction for how to work around it while the fix is pending review: the Settings gear icon in the upper right corner <img width="1161" alt="Screenshot 2020-07-10 at 14 39 06" src="https://user-"the Debugging tab <img width="1275" alt="Screenshot 2020-07-10 at 14 39 13" src="https://user-"the checkmark next to Break on Warnings <img width="1273" alt="Screenshot 2020-07-10 at 14 39 20" src="https://user-"the checkmark next to Break on Warnings <img width="1286" alt="Screenshot 2020-07-10 at 14 39 25" src="https://user-"Now reload the page and you shouldn't be bothered by it.
Please refrain from "same" comments unless you have something new to say. They are not helpful and obscure the workaround ().
Update: The fix has been published to NPM as 4.81 The updated extension (with fix) is live for Firefox The updated extension is pending for Chrome Edge is still providing the previous version 4.7 (but an updated 4.8.1 is also pending for review)
We'll keep this issue open until the fix has been deployed on Chrome, but I'm going to lock it to prevent +1
1 is live in Chrome store now too, so I'm going to close this.
Change:
function sharedTests(label, memo) { describe(`${label}`, () => { it('bails out on props equality', async () => { <del> const {Suspense} = React; </del> function Counter({count}) { return <Text text={count} />; }

Discussion:
<!-- 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? Attempting to assign a ref to a component wrapped in does not produce a friendly error message. Attempting the same thing with a functional component not wrapped in memo gives a descriptive error ("Warning: Function components cannot be given refs. Attempts to access this ref will fail."). 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: I trust this is not needed for this case What is the expected behavior? The same error message as with a non-memo functional component should be displayed. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? 0
Change:
handleKeydown = e => { // only interesting in arrow key events <del> if (![37, 38, 39, 40].includes(e.keyCode)) return; </del> <ins> if ([37, 38, 39, 40].indexOf(e.keyCode) < 0) { return; } </ins> this.setState(({keydownCount}) => { return {

Discussion:
As far as I can tell, the path to the UMD version of React 16 changed, which makes it impossible to test the latest version of React through the test fixtures. We probably need to add a condition to the react loader to change the path above a certain version:
did really resolve this? I thought the problem was the CDN paths we're using?
No. Sorry. I got the wrong issue :(
I fixed in . Still broken for 16 alphas but they’re pretty borked anyway. Might need to blacklist them somehow.
No problem. I a little work around in . It seemed about as good as a blacklist.
Change:
width: 0; margin: 0; opacity: 0; <ins> /* Hide radio buttons for Firefox too */ position:  absolute; </ins> } .IconSizeNavigation,

Discussion:
Website is actually irrelevant, but required. the devtools the settings button. the layout being broken (causing horizontal scrollbar). Screenshot ! Every time No response No response No response No response No response No response
Can you provide some more information? Browser (and version), operating system (and version), DevTools extension version, etc. I can't reproduce this.
Firefox 89, Windows 10, latest extension. It's really not that far-fetched.
I'm not sure why there's hostility in your responses (both to this issue and ). This is a free software product and I'm trying to help you. Providing basic info like browser and operating system version along with a bug report is generally useful, regardless of how far fetched you think the configuration is :smile:
Not sure if this is confirmed by anyone else, but I can reproduce this on Firefox. I'll paste my device information so you can try that out in order to repro. How it looks: ! Machine: Windows 10 Home Browser: Firefox version 89.0.1 (64-bit) Let me know if you need more details, I'll be more than happy to take this up. Update: It also happens on chrome dev tools when you resize your dev tools to some specific width.
If I enable scroll bars on OS X, I can also reproduce this in Firefox. Should be able to fix it then. (Did not have access to a Windows machine to test with.) Edit 1: It looks like this is caused by the tab bar containing too many tabs now (General, Debugging, Components, Profiler, and "x" button). Should be an easy fix. Edit 2: I think the reason for the difference between Firefox and Chrome is that the (supposedly hidden) buttons used for the Tab bar accessibility isn't 0 width for Firefox.
Sorry mate, but I don't understand the question then. You asked for browser & OS, and I gave that exact answer. That's really, honestly, genuinely, everything needed to a repro. I've seen this on every pc running Windows 10 + Firefox so far, which is why it's not that far-fetched. I don't see how that's hostile. And actually, we're trying help each other, aren't we Also how am I responding hostile in ? I'm suggesting a fix. I'm Dutch, so I'm just being direct, not hostile at all. It's my culture, please respect that
Change:
font-family: var(--font-family-sans); } <ins> .Components, .Components * { box-sizing: border-box; -webkit-font-smoothing: var(--font-smoothing); } </ins> .TreeWrapper { flex: 0 0 var(--horizontal-resize-percentage); overflow: auto;

Discussion:
I don't see the selection at all. My version is 4.5.0. I think this regressed. <img width="266" alt="Screenshot 2020-03-11 at 23 40 37" src="https://user-"
This is interesting. The extension seems to have a shorter toolbar height than I would expect, which is clipping the current index. Here's what the test harness/shell looks like: <img width="437" alt="Screen Shot 2020-03-11 at 6 11 50 PM" src="https://user-"
Looks like something is going wrong with the relative height of the list items in the extension. Works fine in Chrome but it's overflowing in the extension.
Ah, it looks like the style isn't cascading correctly in the extension.
I think this probably regressed with , because the extension uses portals to mount (so they don't get mounted underneath of the class).
Yay! Fixed. <img width="369" alt="Screen Shot 2020-03-11 at 6 35 52 PM" src="https://user-"
Change:
}); var shallowRenderer = ReactTestUtils.createRenderer(); <del> shallowRenderer.render(<SomeComponent />, {}); </del> <ins> shallowRenderer.render(<SomeComponent />); </ins> var result = shallowRenderer.getRenderOutput();

Discussion:
I am trying to render a component using the preliminary shadow renderer support in TestUtils. A simple reproducible test case of my issue is this When I run this in my Jest test, I get: It looks like this error is thrown whenever the component being rendered has . I thought perhaps the context was required (although I haven't had any problems omitting it in my actual app), but even when using I get the same exception.
I think this is a known issue with shallow rendering. cc
thanks for the report. Context isn't meant to be supported with shallow rendering (i.e., we haven't tested it), but it looks like you may be able to work around this problem by passing an object as the second argument to : it looks like an additional argument was to the shallow rendering API in . What was the thinking here? Can we default this to an empty object?
Thanks, the workaround works great. And I see you posted a fix as well so looking forward to that.
Change:
expect( Object.keys(testInstance.refs || {}).filter(key => testInstance.refs[key]) .length, <del> ).toEqual(1); </del> <ins> ).toEqual(2); </ins> ReactDOM.unmountComponentAtNode(container); expect( Object.keys(testInstance.refs || {}).filter(key => testInstance.refs[key])

Discussion:
Do you want to request a feature or report a bug? Bug What is the current behavior? If you remove the ref from a mounted HostComponent on an update, it calls the original ref with null. If you remove the ref from a mounted ClassComponent on an update, it does not call the original ref with null. Note that it doesn't call ref1 (passed to FooInner as ref) with null Note that it does call ref1 (passed to div as ref) with null If you modify the ref from either a HostComponent or a ClassComponent (change from to ), the original ref (ref1) is called with null and the new ref (ref2) is called with the instance. (take the sandboxes above and change the second to What is the expected behavior? Honestly not sure but it should be consistent. The reason this is different is because for HostComponents, as long as . For ClassComponents, as long as -- which means if is null, the behavior is different (hence this issue). We should probably pick one and make it consistent. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Unsure - it for sure is an issue in latest/Fiber, but I haven't dug deep enough to see what happened in <16.
Change:
*/ function createSourceCodeErrorMessage(code, e) { var sourceLines = code.split('n'); <ins> // e.lineNumber is non-standard so we can't depend on its availability. If // we're in a browser where it isn't supported, don't even bother trying to // format anything. We may also hit a case where the line number is reported // incorrectly and is outside the bounds of the actual code. Handle that too. if (!e.lineNumber || e.lineNumber > sourceLines.length) { return ''; } </ins> var erroneousLine = sourceLines[e.lineNumber - 1]; // Removes any leading indenting spaces and gets the number of

Discussion:
When attempting to use a react class with a lowercase ClassName, the transformer is not able to display line on which the error occurred. It turns out that the event variable passed to the to function does not contain an attribute called lineNumber. An error is thrown that states: Uncaught TypeError: Cannot read property 'replace' of undefined The actual error has only the properties and . Error: Lower case component names (myClass) are no longer supported in JSX: See at
What environment/browser are you in?
I am running Yosemite and in Chrome. Also using the jsxtransformer and react provided by the CDN. On Tuesday, November 25, 2014, Paul O’Shannessy wrote: Cooper Union EE' 14
Change:
// Fibers only store the current context value, // so we need to track them separately in order to determine changed keys. function crawlToInitializeContextsMap(fiber: Fiber) { <del> updateContextsForFiber(fiber); let current = fiber.child; while (current !== null) { crawlToInitializeContextsMap(current); current = current.sibling; </del> <ins> const id = getFiberIDUnsafe(fiber); // Not all Fibers in the subtree have mounted yet. // For example, Offscreen (hidden) or Suspense (suspended) subtrees won't yet be tracked. // We can safely skip these subtrees. if (id !== null) { updateContextsForFiber(fiber); let current = fiber.child; while (current !== null) { crawlToInitializeContextsMap(current); current = current.sibling; } </ins> } }

Discussion:
not public I have two code bases in a yarn workspaces linked monorepo. One is using react-three-fiber (the lib), and the other one is really thin wrapper around it with some simple UI, just couple of buttons. Both are using multiple (3) zustand stores. Every time react-devtools-extensions 21.0- Could not find ID for Fiber "App"
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 have experienced the same issue in Firefox, also with the use of react-three-fiber and zustand. If it helps isolate the issue, I only experience it for development builds but do not experience it for production builds. Repository: Browser: Firefox 95.0.2 (64-bit), Windows 10 Sample video: https://user- The error message in the pane:
Thanks for the repro,
I, too, have had this issue and spent a bit of time reducing the surface area to a really small combo of react + canvas. Hopefully, this breaks in a way that is helpful. DevTools version Error message Error call stack Error component stack GitHub query string !
Possibly fixed by . Possible requires an additional change made to this method to replace with (and we can just skip Fibers with a null ID).
Repro from by repo repo in your browser of choice. to the dev tools, and you should see the error
Fix released on Jan 24 as version 4.23.0: Give it a couple of days to propagate to all of the browsers. (Chrome usually takes the longest.)