Question: }, "dependencies": { "cross-spawn": "^5.0.1", <del> "electron": "^9.1.0", </del> <ins> "electron": "^11.1.0", </ins> "ip": "^1.1.4", "minimist": "^1.2.3", "react-devtools-core": "4.10.1",

macOS 11.0.1 Big Sur, on an Apple Silicon (M1) chip React 17.0.1 React DevTools 4.10.1, running in standalone mode via Electron 11.1.0 (darwin-arm64 build) New project using create-react-app . with the useScript hook to add the <scripttag required by React DevTools. React DevTools to a project with (or yarn). -devtools expects Electron 9.x.x; however builds for darwin-arm64 are only available for 11.1.0. Installation fails with: Link to code example: Workarounds are ; however a 11.1.0 build is required. Bump the version in so this works out of the box.
Want to submit a PR (and test the bump)?
I can look into this
Okay.
Just wanted to add that bumping the version works well. <img width="1027" alt="image" src="https://user-"
Hi are you working on this? If not, I'd like to take this issue.
Sure im looking into another issue you can take it up!
I can update electron package version
[devtools] Bump electron version from 9.1.0 to 11.1.0 for darwin-arm64 builds
So, I think need close this issue
I think they'll close it once the PR is merged
How can we install this bumped version from github pull request? without waiting to be merged?
You'll have to clone my forked repo and build from source. You can find the instructions to build
Can someone please tell how to use resolutions ? I am macbook pro m1 and when I hit the command -It gives the following error What I tried is I downloaded the react devtools 4.10.1 in my local system and tried install it using Then I installed react-native-debugger and then again got the same issue. Unsupported DevTools backend version You are running react-devtools version 4.13.4-. This requires bridge protocol version 1. However the current backend version uses bridge protocol version 0.

To fix this, downgrade the DevTools NPM package:
My dirty workaround, things seem to work fine on my M1 machine: Install Electron 11 globally Install react-devtools without the binary download Remove the existing folder and in the react-devtools electro module - Symlink the global electron installation to the react-devtools electron module installation - I also had to update the package inside my global installation to 4.11.0 (could use the same symlinking logic there too I guess)
thanks for me, just the first two steps worked on my M1 machine Install Electron 11 globally npm i -g electron Install react-devtools without the binary download ELECTRONSKIPBINARY_DOWNLOAD=1 npm i -g react-devtools
I had to follow the steps in mixed with 's steps. I'm using a mac M1 which gives the error So I used the following modified steps:
The response by works perfectly. Thanks. Just replace by the wanted version. For example for me i wanted react-devtools 4.10.4 (the inspector couldn't inspect anything up this version) So i just changed and .


Question: */ function createLinkTypeChecker(linkType) { var shapes = { <del> value: typeof linkType === 'undefined' ? </del> <ins> value: linkType === undefined ? </ins> React.PropTypes.any.isRequired : linkType.isRequired, requestChange: React.PropTypes.func.isRequired,

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.


Question: setSelection: function(input, offsets) { var start = offsets.start; var end = offsets.end; <del> if (typeof end === 'undefined') { </del> <ins> if (end === undefined) { </ins> end = start; }

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.


Question: box-shadow: 0 2px 4px var(--color-shadow); border-radius: 0.25rem; overflow: auto; <del> width: 400px; </del> <ins> width: 410px; </ins> max-width: 100%; }

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


Question: { "name": "react-devtools", <del> "version": "5.3.1", </del> <ins> "version": "6.0.0", </ins> "description": "Use react-devtools outside of the browser", "license": "MIT", "repository": {

development website Uncaught Error: getCommitTree(): Invalid commit "1" for root "1". There are only "1" commits. Every time react-devtools-extensions 1- getCommitTree(): Invalid commit "2" for root "1". There are only "1" commits.
Hi thank you for reporting. should fix this. It's scheduled to be included in DevTools 6.0.0. Let us know if it's still happening in 6.0.0


Question: topLevelType, topLevelTarget, topLevelTargetID, <del> nativeEvent </del> <ins> nativeEvent, nativeEventTarget </ins> ) { return [ extractCompositionEvent( topLevelType, topLevelTarget, topLevelTargetID, <del> nativeEvent </del> <ins> nativeEvent, nativeEventTarget </ins> ), extractBeforeInputEvent( topLevelType, topLevelTarget, topLevelTargetID, <del> nativeEvent </del> <ins> nativeEvent, nativeEventTarget </ins> ), ]; },

I tried updating from to . Something has changed in between these releases that is making it so that in onChange's synthetic event is undefined.
This appears to be related to a bug in . does not accept the argument and does not pass it on to . However that's not the only fix needed, also needs to pass something in place of the that expects. Also it seems has the same issue with being passed. I tried fixing this myself. However I have issues with the test setup and/or the test utils seem incapable of triggering from .
Yes I can confirm I have this issue too! This unfortunately makes the beta unusable in my app. The is null while the native event has a target
Same issue. The workaround is using instead of . But that's kinda wrong :(
Same here, but you can use for now.
Excuse me. I'm a beginners of React. Can I ask a question? Why can I use "jsx -watch src/build" to translate "" file to plain JavaScrip?
In fact, I can't see any result after do all steps
I don't know, but this is not the place for asking such questions. Ask this on Stackoverflow or IRC / Slack channels maybe
Thank you for your answer.


Question: { "name": "react-devtools-core", <del> "version": "4.27.7", </del> <ins> "version": "4.27.8", </ins> "description": "Use react-devtools outside of the browser", "license": "MIT", "main": "./dist/backend.js",

local repo Loading a React component with the React profiler recording enabled Every time react-devtools-extensions 27.6- Cannot add node "1751" because a node with that id is already in the Store. No response
! Same issue here. Devtools version: 4.27.6 (4/20/2023)
Same issue here. Using NextJS 13.4.1 !
Same issue here. Happens, when adding Canvas element. version 8.13.0 <img width="682" alt="Снимок экрана 2023-05-10 в 22 31 40" src=""
Same issue: !
same... do you all have code for a chrome extension?
same with devtools version: 4.27.7 (5/7/2023) !
I've installed a React profiler via Chrome web store () which created a second copy of an extension under "From other sources" title in extensions panel, after that I've deleted a copy of an react dev tools that was 'native' to edge, and voila, profiler works.
Hey folks, the only reproducible example I've found is mentioned in I've merged a fix for it, but need more input from you: you are constantly facing this issue, can you post here a repro please? you please follow and try to reproduce this error again?
I am no longer seeing this error after installing the release you linked in .
Great, thank you! This fix will be included in v4.27.8 release, which I will publish this week.


Question: <del> 'use strict'; var fs = require('fs'); var grunt = require('grunt'); var src = 'gem-react-source/'; var dest = 'build/gem-react-source/'; var build = dest + 'build/'; var buildFiles = [ 'react.js', 'react.min.js', 'JSXTransformer.js', 'react-with-addons.js', 'react-with-addons.min.js', ]; function buildRelease() { if (grunt.file.exists(dest)) { grunt.file.delete(dest); } // Copy gem-react-source/**/* to build/gem-react-source var mappings = [].concat( grunt.file.expandMapping('**/*', dest, {cwd: src}) ); mappings.forEach(function(mapping) { var mappingSrc = mapping.src[0]; var mappingDest = mapping.dest; if (grunt.file.isDir(mappingSrc)) { grunt.file.mkdir(mappingDest); } else { grunt.file.copy(mappingSrc, mappingDest); } }); // Make built source available inside npm package grunt.file.mkdir(build); buildFiles.forEach(function(file) { grunt.file.copy('build/' + file, build + file); }); } function packRelease() { var done = this.async(); var spawnCmd = { cmd: 'gem', args: ['build', 'react-source.gemspec'], opts: { cwd: dest, }, }; grunt.util.spawn(spawnCmd, function(err, result) { if (err) { grunt.log.error(err); } // Gem packing does weird things to versions so 0.12.0-alpha becomes // 0.12.0.pre.alpha. We need to get the filename printed to stdout. var filename = result.stdout.match(/File: (.*)$/)[1]; var buildSrc = 'build/gem-react-source/' + filename; var buildDest = 'build/react-source.tgz'; fs.rename(buildSrc, buildDest, done); }); } module.exports = { buildRelease: buildRelease, packRelease: packRelease, }; </del>

I'm not sure how much value there really is in this. react-rails already stopped using it and just builds the files in itself. cc
(I'm currently running to find out how many there might be - looks like this script may take a day to hit the end point for every gem in the registry)
:+1: I made but it's just a toy :)


Question: * renders >,<, and & as multiple children with clean client render * renders >,<, and & as multiple children with client render on top of good server markup * throws when rendering a string component with server string render <ins> * throws when rendering a string component with clean client render * throws when rendering a string component with client render on top of bad server markup </ins> * throws when rendering an undefined component with server string render <ins> * throws when rendering an undefined component with clean client render * throws when rendering an undefined component with client render on top of bad server markup </ins> * throws when rendering a number component with server string render <ins> * throws when rendering a number component with clean client render * throws when rendering a number component with client render on top of bad server markup </ins> * throws when rendering null with server string render * throws when rendering null with clean client render * throws when rendering null with client render on top of bad server markup

I think something like this both throws and prints success. This means that it is not safe to wrap this in a Promise like this for example: Because if this throws, then the error is silenced. The Promise was already resolved. I hit this in the ServerIntegration-test
Related:
has no render callbacks so I guess we're just not going to fix it in the old API.


Question: <ins> /** * Copyright (c) 2013-present, Facebook, Inc. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. * * @providesModule Wedge.art * @typechecks * * Example usage: * <Wedge *   outerRadius={50} *   startAngle={0} *   endAngle={360} *   fill="blue" * /> * * Additional optional property: *   (Int) innerRadius * */ 'use strict'; var assign = require('object-assign'); var PropTypes = require('prop-types'); var React = require('react'); var ReactART = require('react-art'); var createReactClass = require('create-react-class'); var Shape = ReactART.Shape; var Path = ReactART.Path; /** * Wedge is a React component for drawing circles, wedges and arcs.  Like other * ReactART components, it must be used in a <Surface>. */ var Wedge = createReactClass({ displayName: 'Wedge', propTypes: { outerRadius: PropTypes.number.isRequired, startAngle: PropTypes.number.isRequired, endAngle: PropTypes.number.isRequired, innerRadius: PropTypes.number, }, circleRadians: Math.PI * 2, radiansPerDegree: Math.PI / 180, /** * _degreesToRadians(degrees) * * Helper function to convert degrees to radians * * @param {number} degrees * @return {number} */ _degreesToRadians: function _degreesToRadians(degrees) { if (degrees !== 0 && degrees % 360 === 0) { // 360, 720, etc. return this.circleRadians; } else { return degrees * this.radiansPerDegree % this.circleRadians; } }, /** * _createCirclePath(or, ir) * * Creates the ReactART Path for a complete circle. * * @param {number} or The outer radius of the circle * @param {number} ir The inner radius, greater than zero for a ring * @return {object} */ _createCirclePath: function _createCirclePath(or, ir) { var path = Path(); path.move(0, or).arc(or * 2, 0, or).arc(-or * 2, 0, or); if (ir) { path .move(or - ir, 0) .counterArc(ir * 2, 0, ir) .counterArc(-ir * 2, 0, ir); } path.close(); return path; }, /** * _createArcPath(sa, ea, ca, or, ir) * * Creates the ReactART Path for an arc or wedge. * * @param {number} startAngle The starting degrees relative to 12 o'clock * @param {number} endAngle The ending degrees relative to 12 o'clock * @param {number} or The outer radius in pixels * @param {number} ir The inner radius in pixels, greater than zero for an arc * @return {object} */ _createArcPath: function _createArcPath(startAngle, endAngle, or, ir) { var path = Path(); // angles in radians var sa = this._degreesToRadians(startAngle); var ea = this._degreesToRadians(endAngle); // central arc angle in radians var ca = sa > ea ? this.circleRadians - sa + ea : ea - sa; // cached sine and cosine values var ss = Math.sin(sa); var es = Math.sin(ea); var sc = Math.cos(sa); var ec = Math.cos(ea); // cached differences var ds = es - ss; var dc = ec - sc; var dr = ir - or; // if the angle is over pi radians (180 degrees) // we will need to let the drawing method know. var large = ca > Math.PI; // TODO (sema) Please improve theses comments to make the math // more understandable. // // Formula for a point on a circle at a specific angle with a center // at (0, 0): // x = radius * Math.sin(radians) // y = radius * Math.cos(radians) // // For our starting point, we offset the formula using the outer // radius because our origin is at (top, left). // In typical web layout fashion, we are drawing in quadrant IV // (a.k.a. Southeast) where x is positive and y is negative. // // The arguments for path.arc and path.counterArc used below are: // (endX, endY, radiusX, radiusY, largeAngle) path .move(or + or * ss, or - or * sc) // move to starting point .arc(or * ds, or * -dc, or, or, large) // outer arc .line(dr * es, dr * -ec); // width of arc or wedge if (ir) { path.counterArc(ir * -ds, ir * dc, ir, ir, large); // inner arc } return path; }, render: function render() { // angles are provided in degrees var startAngle = this.props.startAngle; var endAngle = this.props.endAngle; if (startAngle - endAngle === 0) { return; } // radii are provided in pixels var innerRadius = this.props.innerRadius || 0; var outerRadius = this.props.outerRadius; // sorted radii var ir = Math.min(innerRadius, outerRadius); var or = Math.max(innerRadius, outerRadius); var path; if (endAngle >= startAngle + 360) { path = this._createCirclePath(or, ir); } else { path = this._createArcPath(startAngle, endAngle, or, ir); } return React.createElement(Shape, assign({}, this.props, {d: path})); }, }); module.exports = Wedge; </ins>

It seems like those were intended to be public APIs () but they’re not published on npm because folder is not in the whitelist.


Question: ): void { for (let i = 0; i < hooksTree.length; i++) { const hook = hooksTree[i]; <ins> if (isUnnamedBuiltInHook(hook)) { // No need to load source code or do any parsing for unnamed hooks. if (__DEBUG__) { console.log('flattenHooksList() Skipping unnamed hook', hook); } continue; } </ins> hooksList.push(hook); if (hook.subHooks.length > 0) { flattenHooksList(hook.subHooks, hooksList);

Hooks like or will never have names, so if a the only hooks for a given source file are these "unnamed" built-in hooks, we should skip loading the source code.


Question: ); }); <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');

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.


Question: The uncompressed, development version of [react.js](https://fb.me/react-{{site.react_version}}.js) and [react-dom.js](https://fb.me/react-dom-{{site.react_version}}.js) with inline documentation (you need both files). ```html <del> <script src="https://fb.me/react-{{site.react_version}}.js" integrity="sha384-{{site.react_hashes.dev}}" crossorigin="anonymous"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.js" integrity="sha384-{{site.react_hashes.dom_dev}}" crossorigin="anonymous"></script> </del> <ins> <script src="https://fb.me/react-{{site.react_version}}.js"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.js"></script> </ins> ``` #### React {{site.react_version}} (production) The compressed, production version of [react.js](https://fb.me/react-{{site.react_version}}.min.js) and [react-dom.js](https://fb.me/react-dom-{{site.react_version}}.min.js) (you need both). ```html <del> <script src="https://fb.me/react-{{site.react_version}}.min.js" integrity="sha384-{{site.react_hashes.prod}}" crossorigin="anonymous"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.min.js" integrity="sha384-{{site.react_hashes.dom_prod}}" crossorigin="anonymous"></script> </del> <ins> <script src="https://fb.me/react-{{site.react_version}}.min.js"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.min.js"></script> </ins> ``` #### React with Add-Ons {{site.react_version}} (development) The uncompressed, development version of React with [optional add-ons](/react/docs/addons.html). ```html <del> <script src="https://fb.me/react-with-addons-{{site.react_version}}.js" integrity="sha384-{{site.react_hashes.addons_dev}}" crossorigin="anonymous"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.js" integrity="sha384-{{site.react_hashes.dom_dev}}" crossorigin="anonymous"></script> </del> <ins> <script src="https://fb.me/react-with-addons-{{site.react_version}}.js"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.js"></script> </ins> ``` #### React with Add-Ons {{site.react_version}} (production) The compressed, production version of React with [optional add-ons](/react/docs/addons.html). ```html <del> <script src="https://fb.me/react-with-addons-{{site.react_version}}.min.js" integrity="sha384-{{site.react_hashes.addons_prod}}" crossorigin="anonymous"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.min.js" integrity="sha384-{{site.react_hashes.dom_prod}}" crossorigin="anonymous"></script> </del> <ins> <script src="https://fb.me/react-with-addons-{{site.react_version}}.min.js"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.min.js"></script> </ins> ``` All scripts are also available via [CDNJS](https://cdnjs.com/libraries/react/).

Pasting the exact code from into a HTML file and opening it through a Python 3.4 HTTP server for some reason gives the following error in Chrome: I'm able to work around this completely by removing the and attributes from the React and React-Dom script tags: I've never had this issue in Chrome before, and I frequently include external scripts with and attributes with no problem, so I'm lead to believe this may have something to do with the way is configured.
I can’t find mentions of or on that page. Can you help me understand where you see it?
Ah, my mistake, this comes when copying over the elements from the Downloads page: , not the tutorial page. I've updated the main post.
Thanks. I can reproduce this. Can you give any insight into this?
Something like might help.
The problem is that the headers aren't being set on the server, so the python gist is irrelevant / will not solve this issue. This is a security feature of browsers, since checking integrity can leak information about the content of the response. fbcdn does allow all origins, but does not, which is the root cause of the error here. Does serve anything directly, or is always just redirects? If it always just redirects, we might be able to blindly enable the CORS headers on without any security impact (thereby relying on the redirect-destination to control the CORS permissions). Otherwise, we would need to enable the cross-origin headers for individual URLs, which will require adding data to the fburl database, which is probably a more intense task. Another option is to use a different URL (not ). Could link directly to the CDN, for instance. I think the shortest term solution is to remove the offending attributes from the script tag, which makes the tags look cleaner/simpler (read: less scary to new user) anyway.
Oh okay, thanks :+1:
is always a redirect, but I thought it was set up right such that this worked. I thought I checked the headers when I those attributes to the docs... maybe not… I think ultimately we shouldn't use but haven't gone and done that yet. We might just set up a little mini-cdn of our own since we have some other issues with the older links (corrupted cache somewhere that we thought we tracked down but still see occasional issues).

cdnjs and jsdelivr are both great external third-party options right now so I definitely recommend them over regardless. We just need some control when we ship releases so relying on them entirely isn't in the cards. I think we should keep the attributes (when they work) - moving towards a world with these checks is a good thing and we can help promote these features. But shorter-term, yea that's fine.
I've used CloudFront in the past, and can certify that it's totally awesome. FWIW.


Question: 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'

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.


Question: } 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;

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.


Question: ); } }); <ins> JQueryMobileHeader = React.createFactory(JQueryMobileHeader); </ins> /** jQuery Mobile page component. */ var JQueryMobilePage = React.createClass({

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.


Question: 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',

Should the label be removed?
Should be fixed in . Please verify.
Works great now, thanks! Looking forward to the 17.0.0 release.


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

<!-- 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.


Question: 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} />; }

<!-- 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


Question: didError: boolean, ) { const helpers = helpersByRendererID.get(id); <del> if (helpers === undefined) { return; } helpersByRoot.set(root, helpers); const current = root.current; const alternate = current.alternate; // We need to determine whether this root has just (un)mounted. // This logic is copy-pasted from similar logic in the DevTools backend. // If this breaks with some refactoring, you'll want to update DevTools too. if (alternate !== null) { const wasMounted = alternate.memoizedState != null && alternate.memoizedState.element != null; const isMounted = current.memoizedState != null && current.memoizedState.element != null; if (!wasMounted && isMounted) { </del> <ins> if (helpers !== undefined) { helpersByRoot.set(root, helpers); const current = root.current; const alternate = current.alternate; // We need to determine whether this root has just (un)mounted. // This logic is copy-pasted from similar logic in the DevTools backend. // If this breaks with some refactoring, you'll want to update DevTools too. if (alternate !== null) { const wasMounted = alternate.memoizedState != null && alternate.memoizedState.element != null; const isMounted = current.memoizedState != null && current.memoizedState.element != null; if (!wasMounted && isMounted) { // Mount a new root. mountedRoots.add(root); failedRoots.delete(root); } else if (wasMounted && isMounted) { // Update an existing root. // This doesn't affect our mounted root Set. } else if (wasMounted && !isMounted) { // Unmount an existing root. mountedRoots.delete(root); if (didError) { // We'll remount it on future edits. failedRoots.add(root); } else { helpersByRoot.delete(root); } } else if (!wasMounted && !isMounted) { if (didError) { // We'll remount it on future edits. failedRoots.add(root); } } } else { </ins> // Mount a new root. mountedRoots.add(root); <del> failedRoots.delete(root); } else if (wasMounted && isMounted) { // Update an existing root. // This doesn't affect our mounted root Set. } else if (wasMounted && !isMounted) { // Unmount an existing root. mountedRoots.delete(root); if (didError) { // We'll remount it on future edits. failedRoots.add(root); } else { helpersByRoot.delete(root); } } else if (!wasMounted && !isMounted) { if (didError) { // We'll remount it on future edits. failedRoots.add(root); } </del> } <del> } else { // Mount a new root. mountedRoots.add(root); </del> } <ins> // Always call the decorated DevTools hook. </ins> return oldOnCommitFiberRoot.apply(this, arguments); }; } else {

When I use DevTools to select an element on the page, it can't jump/find it. It also doesn't show it in the Components page. This was checked by finding its parent and checking the children, non of the newly generated ones are there. As a probably related bug Profiler doesn't show/record the changes. React version: 16.13.1 React-dom version: 16.13.1 Parcel: 2.0.0-beta.1 a parent element a child element (A) conditional rendering () "hide" A now shows and select B using Chrome Dev Tools's "Select an element in the page to inspect it" nowhere/Can't find it manually in the list. ! In this example, I demonstrate that it works on the Search Bar (light grey bar) which is the TextField=InputBase tree, and the Container that contains the search & images and how hovering over the image doesn't do anything. I then click on the image and nothing happens & the state panel on the right of Dev Tools empties itself. Can't find newly rendered components in React Dev Tools Components panel Being able to find the newly rendered components in React Dev Tools Components panel
It doesn't look like this bug report has enough info for one of us to reproduce it. Please provide a CodeSandbox (), a link to a repository on GitHub, or provide 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:
how "complex"/big of a repo is allowed for me to link to? As so far I have had 0 luck replicating a basic example on codesandbox as it behaves as it should.
The smaller it is, the better chance someone will be able to look at it and find/fix the problem.
So it appears the issue is Google-Analytics. If I remove the code it is fine, add it, and it breaks. As such I have created a branch where I have removed basically all of the code except what is really needed to show this breaking.

In order to repo repo i start to HTTP://localhost:1234 into Chrome Dev Tools (Ctrl+Shift+i) to components (Figure 1) page that only App/Homepage/OfficialServers/Guilds show (Figure 1) to lines 10 to 23 aka the GA stuff will rebuild and reload page back to Chrome Dev Tools there is a lot more content (Figure 2) Figure 1 ! Figure 2 ! Hopefully, this is more helpful :)
Thanks for the info :) I'll tag this as "needs investigation" in case anyone has bandwidth to dig in.
Thanks man :)
I can't reproduce the broken behavior your screenshot shows using this repo. For me, the nested and components are visible with GA or without. Passing the issue back to you for more repro instructions. You might need to dig in and see if any errors are being thrown by DevTools. There might also be another web extension you have installed that is making this happen.
Interesting note, when I just swapped branch to it, it worked fine (aka didn't break), but after running a it broke again properly. I had a range of extensions (not mentioning as it currently doesn't seem needed), so I disabled them all except React Dev Tools to obviously show the results. But it still broke. I then swapped to checking the Console, below you can see the results of it. This was after clearing the console then F5. ! I am not going to link the files as they are massive, but they start with (top down) Hope this helps
I don't really see anything useful in that console. Am I suppose to? The source map warning is unrelated. Also not sure I understand how those JSON files are supposed to be related, sorry.
Honestly same, I was just praying that something in there made sense for what or why this is happening at the moment. I am currently unsure of what to test tbh. Could it be browser dependant? I am currently testing this all in Chrome: 86.0.4240.75 maybe it doesn't occur in other browsers?
Sorry, what I meant was that I don't really understand your latest comment. I don't think the JSON files are useful/usable by me in any way to reproduce this issue? And the console warnings are definitely not related to what you're reporting.

I am testing on OS X with Chrome 86.0.4240.111.
I was able to repro this with a fresh install of the linked repo. It seems that any script tag after the one that loads the react app module will cause this issue, in this case . I removed GA entirely and just a simple console log. Example here: And the issue still occurred. Moving the script above resolves it: I know that the React documentation recommends putting the , but I don't think this is expected behavior for the dev tools since the rest of the application works fine. But it's worth noting that putting or with the script tag will make browsers load that script last. I also removed the API call and had it load the data by default, and could see everything in the components tree. So this probably isn't an issue related conditional rendering, but rather it's ability to catch re-renders and updates when the react module isn't the last script the browser loads.
I'm confused by this statement. The docs section you linked to just shows loading React before loading your component code that uses React– and that's only applicable if you're using UMD builds (loading code into the global/window namespace). I am not aware of any reason why additional tags being present in the page should have any impact on React DevTools (and I don't see the behavior being described when running the repro app).
Update, I was using Firefox 81.0.2 and same issue. Also I am on Windows, but I doubt that is the issue. Doing a was able to trigger it. I was also able to mirror the fix that had, by moving the under the GA code.
You're right, my apologies! It really shouldn't, I was just reporting what I was experiencing when trying to reproduce the issue. It so far has consistently worked when no other script follows in execution order, but fails when one does. I am on macOS with Chrome 86.0.4240.111. Also tried it on Windows, experienced the same issue. I tried to recreate the issue on codesandbox, but was unable to. I did notice that the version of React DevTools available on codesandbox is , while I'm using , so that could be why it's difficult to get this behavior on there!
Just tried the steps again and I still can't repro the issue.

Might be worth pointing out that my app doesn't look anything like yours. Your screenshot shows: But when I run the repro app, I see: I assume this is expected because it's just a reduced repro case, but just wanted to clarify. I'm going to need one of you to dig into this and provide some more info. I can't trigger the problem, so there's not much I can do on this end to help. Does the console show any errors that might be related? (None of the ones in the screenshot above looked related but are there others?) If you detach the browser DevTools panel and open a second DevTools– does that DevTools have any errors (coming from one of your installed extensions) that might be related? !
I think the link they shared for the repo included a specific commit that they put the reduced code, instead of it being in master. Did you checkout the commit they shared @ ? Just wondering since your example looks different from what I got when trying to repro as well! For me, there were no related errors in the console or the devtools.
I followed the repro steps above, exactly: I assume that you did as well? If you have to do something else to repro this, that would be helpful to know.
They mentioned in their comment they created a new branch, so I guess I expanded step 1 from their steps into: - -
Thanks Let me try that.
Ah! That was the missing step. This is interesting. Checking out that branch: If I load the page, then open DevTools, it looks fine. If I open DevTools and then (re)load the page, some components are missing.
Interesting to note that I stepped all the way back to DevTools v4.0.0 and this bug still happens. This is definitely not a recent regression.
It's also interesting to note that I can't repro this with the DevTools extension detached (and logging debug info) only when it's docked to the bottom and I reload the page after it was already open. That's going to make it a little harder to track down.
I've been able to reduce the repro to the following: Unfortunately I have not been able to reproduce the failing behavior in one of our integration tests. Still, a small repro is very promising.

Going to dig into the actual code now and see what's breaking :smile:
Very nice work :D Glad I wasn't losing the plot, weird how picky it is in regards to the DevTools behaviour
I think this bug is actually being caused by Fast Refresh bailing out without calling the decorated DevTools hook: Although it seems sensitive to timing so I'm having trouble catching it in the debugger.
Conceptually, it's possible for Fast Refresh to intercept a renderer that it isn't compatible with: In which case, subsequent commits from react-dom will effectively block DevTools entirely: This looks wrong. FR should always pass through to DevTools.
Thanks for the fix :)


Question: 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 {

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.


Question: width: 0; margin: 0; opacity: 0; <ins> /* Hide radio buttons for Firefox too */ position:  absolute; </ins> } .IconSizeNavigation,

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


Question: 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;

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-"


Question: }); var shallowRenderer = ReactTestUtils.createRenderer(); <del> shallowRenderer.render(<SomeComponent />, {}); </del> <ins> shallowRenderer.render(<SomeComponent />); </ins> var result = shallowRenderer.getRenderOutput();

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.


Question: 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])

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.


Question: */ 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

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


Question: // 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> } }

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.)


Question: #### React Core {{site.react_version}} (production) The compressed, production version of React core  ```html <script src="http://fb.me/react-{{site.react_version}}.min.js"></script> ```  #### React Core {{site.react_version}} (development) The uncompressed, development version of React core with inline documentation.  ```html <script src="http://fb.me/react-{{site.react_version}}.js"></script> ```  #### JSX Transform The JSX transformer used to support [XML syntax](/react/docs/syntax.html) in JavaScript.  ```html <script src="http://fb.me/JSXTransformer-{{site.react_version}}.js"></script> ```  ## Bower ```sh

This is a feature request. In React v15.6, HTMLDOMPropertyConfig, SVGDOMPropertyConfig, and ARIADOMPropertyConfig are available by them directly, e.g. . In v16, however, they are no longer available. I think they are not public parts of react-dom, but they are inevitable to implement , a library to build React DOM from an HTML text. See for how to use them.
I don't think we plan to expose them directly. Their format sometimes changes and we want to be able to make more under the hood changes to them in the future. While it is a bit annoying I encourage you to just copy and paste them (and update if you notice changes on our side).
I've created a package from .


Question: "node": ">=0.10.0" }, "dependencies": { <del> "envify": "^2.0.0" </del> <ins> "envify": "^3.0.0" </ins> }, "browserify": { "transform": ["envify"]

Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed.

Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond


Question: 'polyfill in older browsers.', ); } else if (typeof requestIdleCallback !== 'function') { <del> // Wrap requestAnimationFrame and polyfill requestIdleCallback. </del> <ins> // Polyfill requestIdleCallback. </ins> var scheduledRAFCallback = null; var scheduledRICCallback = null;

We don't use rAF for scheduling anything anymore, yet we still enable it in ReactDOMFrameScheduling. It can probably be simplified a bit by not exposing it.


Question: // Style must be explicitly set in the attribute list. React components // expect a style object style: 0, <ins> // Keep it in the whitelist because it is case-sensitive for SVG. tabIndex: 0, </ins> // itemScope is for for Microdata support. // See http://schema.org/docs/gs.html itemScope: HAS_BOOLEAN_VALUE,

See the original report in The problem is that SVG is case sensitive, and so naïvely setting and relying on insensitivity won't work with it. The good news is it seems like is the only valid with this problem. We just missed it because it applies both to HTML and SVG. I think the fix is to add it back to the whitelist.
simple example where tabbing works & doesn't work depending on case Note that the console does not state the error did you mean not being Not really sure why this is but it does display in our app.
Thanks for confirming this issue, I've been struggling to identify the reason my svg component stopped working after the update. A component made of clickable <circleshave lost both focus and blur functionality, because "tabIndex" is rendered in the camelCase style and then ignored by the browser. I've tried adding the property "tabindex" to the <circletag in the jsx, but it was swallow by React and not rendered to the final component.
React has been released. Please update , , and (if you use it) to this version and let us know if it solved the issue! We’d appreciate if you could test before Monday when we plan to get out.
apologies just seeing this message now. Yes. The issue is resolved with the beta, rc & 16.1


Question: // In IE8, we can capture almost all .value changes by adding a // propertychange handler and looking for events with propertyName // equal to 'value' <del> // In IE9, propertychange fires for most input events but is buggy and </del> <ins> // In IE9-11, propertychange fires for most input events but is buggy and </ins> // doesn't fire when text is deleted, but conveniently, selectionchange // appears to fire in all of the remaining cases so we catch those and // forward the event if the value has changed

Check: Tested in IE10. Likely related to .
We're having issues with this too and had to put in a workaround to deal with it. is this on your roadmap?
Having the same issue with on using IE 11.0.
I have the same issue as when adding a placeholder a textarea, with no value, the onChange event is fired.
I hava the same issue. A input with a placeholder and no value, the onChange event is fired.

See for example code. When setting and removing focus from an empty field with some text, the event is triggered for IE 11 (I have not tested older versions). It does not trigger for other browsers. My current work-around is to test the that was last passed to the input with what is returned by , and only act if they are different, but it would be nice if React would not send the change-event in the first place.
Sounds like a browser quark that we should normalize against, right? Is there anything other than value that we would need to check?
Yeah, this seems odd. Probably on the challenging side for a first bug, but it would be good to figure out why this is happening and how we can prevent it, while still making it possible to type the placeholder text in directly as says.
, not really related but I imagine both could be solved by a similar fix.
Also goes for IE10.


Question: "manifest_version": 3, "name": "React Developer Tools", "description": "Adds React debugging tools to the Chrome Developer Tools.", <del> "version": "4.27.7", "version_name": "4.27.7", </del> <ins> "version": "4.27.8", "version_name": "4.27.8", </ins> "minimum_chrome_version": "102", "icons": { "16": "icons/16-production.png",

local repo Loading a React component with the React profiler recording enabled Every time react-devtools-extensions 27.6- Cannot add node "1751" because a node with that id is already in the Store. No response
! Same issue here. Devtools version: 4.27.6 (4/20/2023)
Same issue here. Using NextJS 13.4.1 !
Same issue here. Happens, when adding Canvas element. version 8.13.0 <img width="682" alt="Снимок экрана 2023-05-10 в 22 31 40" src=""
Same issue: !
same... do you all have code for a chrome extension?
same with devtools version: 4.27.7 (5/7/2023) !
I've installed a React profiler via Chrome web store () which created a second copy of an extension under "From other sources" title in extensions panel, after that I've deleted a copy of an react dev tools that was 'native' to edge, and voila, profiler works.
Hey folks, the only reproducible example I've found is mentioned in I've merged a fix for it, but need more input from you: you are constantly facing this issue, can you post here a repro please? you please follow and try to reproduce this error again?
I am no longer seeing this error after installing the release you linked in .
Great, thank you! This fix will be included in v4.27.8 release, which I will publish this week.


Question: <ins> /** * Copyright (c) Facebook, Inc. and its affiliates. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. * * @flow */ const {useState} = require('react'); const {useCustom} = require('./useCustom'); function Component(props) { const [count] = useState(0); useCustom(); return count; } module.exports = {Component}; </ins>  No newline at end of file

Hooks like or will never have names, so if a the only hooks for a given source file are these "unnamed" built-in hooks, we should skip loading the source code.


Question: return function(done) { spawn( <del> process.execPath, </del> <ins> path.join('node_modules', '.bin', 'eslint' + extension), </ins> [ <del> path.join('node_modules', '.bin', 'eslint' + extension), </del> '.', ], {

"npm run lint" fails on Windows, at least Windows 7. Error: Screenshot: ! I found this but I couldn't fix it anyway. What might it be?
I encountered the same problem. If you look into the code in , you'll find the following code: which spawns a new process using the command "node node_modules.bin .". The command tries to interpret a batch file using node. However node can interpret js files only. That's why there's a SyntaxError. A change like this should work as expected:
Would you like to send a PR if you have a working fix?
Sure. I'll fix the same problem in gulp flow task too.
I rolled this into


Question: * ${license} */ <del> ${source}`; </del> <ins> (function(){${source}})();`; </ins> }, /***************** NODE_DEV *****************/

React version: 16.13.1 Even though React's code (and other packages like ReactDOM) are wrapped in a IIFE, the code applies an entire script strict mode by placing a 'use strict' before any other statement: MDN mentions the "trap" of concatenating conflicting scripts strict mode when using the entire script strict mode, see . a file with React's code at the top and concat an expression that causes a 'use strict' violation this file as a script tag Link to code example: (Scroll to bottom of file to see the concatenated expressions) 'use strict' mode is enforced on all the concatenated code, even if it was not defined as 'strict'. As a result, 'strict' violations at the other concatenated libraries will now throw errors (instead of silencing them), causing the script to stop execution. Global 'use strict' should not be used and should be replaced with function scope strict mode (which already exist in some cases of React IIFE bundles code wrappers, like ). - Always wrap UMD bundles in IIFEs - options for the build script stating - explained (vs )
Thanks for the super quick handling!


Question: if (oldProps !== props) { if (typeof this._instance.componentWillReceiveProps === 'function') { <del> if (__DEV__) { if (warnAboutDeprecatedLifecycles) { const componentName = getName(element.type, this._instance); if (!didWarnAboutLegacyWillReceiveProps[componentName]) { lowPriorityWarning( false, '%s: componentWillReceiveProps() is deprecated and ' + 'will be removed in the next major version. Use ' + 'static getDerivedStateFromProps() instead. Read about the ' + 'motivations behind this change: ' + 'https://fb.me/react-async-component-lifecycle-hooks' + 'nn' + 'As a temporary workaround, you can rename to ' + 'UNSAFE_componentWillReceiveProps instead.', componentName, ); didWarnAboutLegacyWillReceiveProps[componentName] = true; } } } </del> // In order to support react-lifecycles-compat polyfilled components, // Unsafe lifecycles should not be invoked for any component with the new gDSFP. if (typeof element.type.getDerivedStateFromProps !== 'function') {

For consideration. These warnings are already covered by renderers based on react-reconciler. Maybe we don't gain that much by mirroring them in the shallow renderer? Maybe it's not worth the complexity? Particularly with more complicated warnings like the ones being for and .


Question: const server = defaultPort ? `${protocol}://${host}` : `${protocol}://${host}:${port}`; const serverIp = defaultPort ? `${protocol}://${localIp}` : `${protocol}://${localIp}:${port}`; const $ = document.querySelector.bind(document); <del> const $promptDiv = $("#box-content-prompt"); const $confirmationDiv = $("#box-content-confirmation"); </del> let timeoutID; function selectAllAndCopy(event) { const element = event.target; if (window.getSelection) {

Any client that connects to the standalone DevTools While using the standalone DevTools app: a client to the DevTools that client and you should be redirected to the introduction page The event listeners are not re-attached to the splash page elements after the client disconnects. The <scripttags that can be copied on click and the "Profiler tab" link stop working. Every time No response No response No response No response No response No response
I was thinking about two ways to fix this issue: set a MutationObserver to re-attach the listeners when the contents of the root node are changed, or add a callback to the DevToolsUI in the core of the standalone version and re-attach the listeners on that callback.
Nice find! If you'd be interested in submitting a proposal (PR) I'd be happy to review and discuss.
Sure thing, will do!


Question: } function runBatchedUpdates(transaction) { <ins> var len = transaction.dirtyComponentsLength; invariant( len === dirtyComponents.length, 'Expected flush transaction's stored dirty-components length (%s) to ' + 'match dirty-components array length (%s).', len, dirtyComponents.length ); </ins> // Since reconciling a component higher in the owner hierarchy usually (not // always -- see shouldComponentUpdate()) will reconcile children, reconcile // them before their children by sorting the array. dirtyComponents.sort(mountDepthComparator); <del> for (var i = 0; i < dirtyComponents.length; i++) { </del> <ins> for (var i = 0; i < len; i++) { </ins> // If a component is unmounted before pending changes apply, ignore them // TODO: Queue unmounts in the same list to avoid this happening at all var component = dirtyComponents[i];

This throws . Maybe this can be simplified some more but this was the simplest repro I could make. Thanks for sending a repro case over.
Wow, it really was a bug. Narrowed it down a little, but it's still rediculously "complex". Big props to for repro! Anyway, just glancing at the code and from experience, I can safely assume that the issue is that receives multiple updates to the same node from . Which intuitively didn't make any sense at all to me, since always calls when it's done and is basically just recursive. However, when taking another peek at the code, I'm pretty sure that the issue is that (in this case) makes the invalid assumption that all updates belongs to the same root. When that is not the case, an to a component which itself updates another root will only once everything is done. The updates to the other root will NOT after each on that root because will always greater than 0. In practice this means that whenever updates another root, all DOM updates on that root will be batched one after the other (as opposed to batching component updates) which is a violation of assumptions in . It's also very inefficient. Intuitively it seems that what should happen is that all component updates within a call should be (but that is not for sure), exactly how this should be solved in practice I'm not 100% sure right now. But I'm 95% sure that this is what's happening, and the repro does have all the ingredients.
Speaking a bit to in chat, I feel like the issue is that and when called from within become asynchronous as opposed to synchronous as they usually are. Which leads to this issue, but also possibly a lot of other subtle issues.
Apparently is not at all to blame...
Narrowed it down even further, apparently it breaks immediately on the first , the error just didn't show up until later unless prodded.

I still don't feel any more enlightened on the issue though...
Your latest two jsbins (4 & 6) throw different error for me (from in X ): And, if one removes Z from A , the same X throws , because then A render won't have any refs on that render so will be undefined... React docs warn that "Never access refs inside of any component's render method - or while any component's render method is even running anywhere in the call stack.", don't know if it's relevant here.
Yeah different error, but I'm sure the cause is the same. The issue is the span not actually ever being rendered, just that in the old repro it doesn't actually turn into an error until later.
Ok, so perhaps here's a reduced test case, see console: is being called twice in a row, and the first time the span is not there in DOM even though it has been rendered already. One culprit for this behavior may be that you are effectively calling setState on sibling component where setState would not be allowed on component itself (triggered via componentWillUpdate).
Huh? It does end up being rendered in your test case, and there's no error?
no I didn't want to throw the error so that you can see that the componentDidUpdate will be called double. The point is that first the span is not there and if one would try to access it (as in your ref.getDOMNode()) it would throw. See console for flow.
is defined so it's an error regardless, and more than that, React expects the node to be there, but it isn't and throws an error. Even after it still isn't physically there in the DOM. So something is wrong. Unless I'm missing something.
Yes, there is definitely a problem there as you said, sorry for not being clear. I just wanted to reduce it so that there are no refs or forceUpdates which may bring other problems. One could throw the error in componentDidUpdate for clarity, as the innerHTML is definitely empty where it should not be. But it is interesting that it will be called right away again, and then the span will be there.

But it throws:
Was this fixed?
Was clearing up old some old issues and it seemed like this was fixed, but apparently not.
I've found this same problem. Here's a minimal failing example for React 0.12.2: ,output However, it appears that this is fixed in 0.13RC: ,output. Any ideas which commit fixed this? If there aren't tests which exercise this it might creep back in.
Same here. Was perhaps related? I created a simple test case based on jsbin, which currently passes. Unfortunately I'm unable to run tests in anything besides master so can't really validate.
AFAIK no longer exists as of React 0.13, so this issue should be irrelevant now.


Question: var assign = require('Object.assign'); var findDOMNode = require('findDOMNode'); var onlyChild = require('onlyChild'); <ins> var warning = require('warning'); </ins> ReactDefaultInjection.inject();

If we claim to support IE8, and users are testing their code locally in IE8, they might get thrown into compatibility mode by default. This will cause their webapp to blow up, and they will be confused because IE8 is a supported browser. For background, check out this thread: Users can get out of compatibility mode by adding this tag: Since the current failure is cryptic, and it's easy to detect when IE8 is in compatibility mode (), we should probably add a warning to give a hint to the user that even though they're using IE8, they're actually in compatibility mode (effectively IE7) and should add the meta tag or use one of the other various workarounds.


Question: return /^use[A-Z0-9].*$/.test(name); } <del> // Determines whether incoming hook is a primitive hook that gets assigned to variables. export function isNonDeclarativePrimitiveHook(hook: HooksNode) { return ['Effect', 'ImperativeHandle', 'LayoutEffect', 'DebugValue'].includes( hook.name, ); } </del> // Check if the AST Node COULD be a React Hook function isPotentialHookDeclaration(path: NodePath): boolean { // The array potentialHooksFound will contain all potential hook declaration cases we support

Hooks like or will never have names, so if a the only hooks for a given source file are these "unnamed" built-in hooks, we should skip loading the source code.