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

if (type && type.defaultProps) { var defaultProps = type.defaultProps; for (propName in defaultProps) { <del> if (typeof props[propName] === 'undefined') { </del> <ins> if (props[propName] === undefined) { </ins> props[propName] = defaultProps[propName]; } }


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

var range = document.selection.createRange().duplicate(); var start, end; <del> if (typeof offsets.end === 'undefined') { </del> <ins> if (offsets.end === undefined) { </ins> start = offsets.start; end = start; } else if (offsets.start > offsets.end) {


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

var selection = window.getSelection(); var length = node[getTextContentAccessor()].length; var start = Math.min(offsets.start, length); <del> var end = typeof offsets.end === 'undefined' ? </del> <ins> var end = offsets.end === undefined ? </ins> start : Math.min(offsets.end, length); // IE 11 uses modern selection, but doesn't support the extend method.


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

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


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

Component.displayName || Component.name || 'Component'; warning( <del> typeof inst.props === 'undefined' || !propsMutated, </del> <ins> inst.props === undefined || !propsMutated, </ins> '%s(...): When calling super() in `%s`, make sure to pass ' + 'up the same props that your component's constructor was passed.', componentName, componentName


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

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'


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

var renderedComponent = inst.render(); if (__DEV__) { // We allow auto-mocks to proceed as if they're returning null. <del> if (typeof renderedComponent === 'undefined' && </del> <ins> if (renderedComponent === undefined && </ins> inst.render._isMockFunction) { // This is probably bad practice. Consider warning here and // deprecating this convenience.


Question:
The have this at the beginning: But there're a number of instances of JSX in the file. For example, . the note be removed or clarified? JSX be purged from the file? adding tests to this file should they be free of JSX? In certain contexts but not others?
Normally, our style is to use jsx within tests. I think some of the tests explicitly aren't using jsx, and that's the point. Perhaps it would be better to copy-paste that message into each of the tests that doesn't use jsx, since it's easy to miss the note up at the top and having the note at the top is somewhat ambiguous.
Thanks for the feedback. Yeah, for both of those reasons I'd say :+1: to either that or splitting it into two files if that made sense to you (would help with the ease of missing it if it's just at the top and make the alternative of repeating it within the file unnecessary): .
I'd be happy to submit a PR for either of these cases!
I think I prefer having the inline comment copy-pasted. A little copy-pasting never hurt anyone (). I'd take a PR for this, assuming no one else objects.

'use strict'; <del> // NOTE: We're explicitly not using JSX in this file. This is intended to test // classic JS without JSX. </del> var React; var ReactDOM; var ReactTestUtils;


Question:
The have this at the beginning: But there're a number of instances of JSX in the file. For example, . the note be removed or clarified? JSX be purged from the file? adding tests to this file should they be free of JSX? In certain contexts but not others?
Normally, our style is to use jsx within tests. I think some of the tests explicitly aren't using jsx, and that's the point. Perhaps it would be better to copy-paste that message into each of the tests that doesn't use jsx, since it's easy to miss the note up at the top and having the note at the top is somewhat ambiguous.
Thanks for the feedback. Yeah, for both of those reasons I'd say :+1: to either that or splitting it into two files if that made sense to you (would help with the ease of missing it if it's just at the top and make the alternative of repeating it within the file unnecessary): .
I'd be happy to submit a PR for either of these cases!
I think I prefer having the inline comment copy-pasted. A little copy-pasting never hurt anyone (). I'd take a PR for this, assuming no one else objects.

React = require('React'); ReactDOM = require('ReactDOM'); ReactTestUtils = require('ReactTestUtils'); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> ComponentClass = React.createClass({ render: function() { return React.createElement('div');


Question:
The have this at the beginning: But there're a number of instances of JSX in the file. For example, . the note be removed or clarified? JSX be purged from the file? adding tests to this file should they be free of JSX? In certain contexts but not others?
Normally, our style is to use jsx within tests. I think some of the tests explicitly aren't using jsx, and that's the point. Perhaps it would be better to copy-paste that message into each of the tests that doesn't use jsx, since it's easy to miss the note up at the top and having the note at the top is somewhat ambiguous.
Thanks for the feedback. Yeah, for both of those reasons I'd say :+1: to either that or splitting it into two files if that made sense to you (would help with the ease of missing it if it's just at the top and make the alternative of repeating it within the file unnecessary): .
I'd be happy to submit a PR for either of these cases!
I think I prefer having the inline comment copy-pasted. A little copy-pasting never hurt anyone (). I'd take a PR for this, assuming no one else objects.

expect(console.error.argsForCall.length).toBe(0); }); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> it('allows static methods to be called using the type property', function() { spyOn(console, 'error');


Question:
The have this at the beginning: But there're a number of instances of JSX in the file. For example, . the note be removed or clarified? JSX be purged from the file? adding tests to this file should they be free of JSX? In certain contexts but not others?
Normally, our style is to use jsx within tests. I think some of the tests explicitly aren't using jsx, and that's the point. Perhaps it would be better to copy-paste that message into each of the tests that doesn't use jsx, since it's easy to miss the note up at the top and having the note at the top is somewhat ambiguous.
Thanks for the feedback. Yeah, for both of those reasons I'd say :+1: to either that or splitting it into two files if that made sense to you (would help with the ease of missing it if it's just at the top and make the alternative of repeating it within the file unnecessary): .
I'd be happy to submit a PR for either of these cases!
I think I prefer having the inline comment copy-pasted. A little copy-pasting never hurt anyone (). I'd take a PR for this, assuming no one else objects.

expect(console.error.argsForCall.length).toBe(0); }); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> it('identifies valid elements', function() { var Component = React.createClass({ render: function() {


Question:
The have this at the beginning: But there're a number of instances of JSX in the file. For example, . the note be removed or clarified? JSX be purged from the file? adding tests to this file should they be free of JSX? In certain contexts but not others?
Normally, our style is to use jsx within tests. I think some of the tests explicitly aren't using jsx, and that's the point. Perhaps it would be better to copy-paste that message into each of the tests that doesn't use jsx, since it's easy to miss the note up at the top and having the note at the top is somewhat ambiguous.
Thanks for the feedback. Yeah, for both of those reasons I'd say :+1: to either that or splitting it into two files if that made sense to you (would help with the ease of missing it if it's just at the top and make the alternative of repeating it within the file unnecessary): .
I'd be happy to submit a PR for either of these cases!
I think I prefer having the inline comment copy-pasted. A little copy-pasting never hurt anyone (). I'd take a PR for this, assuming no one else objects.

expect(typeof Component.specialType.isRequired).toBe('function'); }); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> it('is indistinguishable from a plain object', function() { var element = React.createElement('div', {className: 'foo'}); var object = {}; expect(element.constructor).toBe(object.constructor); }); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> it('should use default prop value when removing a prop', function() { var Component = React.createClass({ getDefaultProps: function() {


Question:
The have this at the beginning: But there're a number of instances of JSX in the file. For example, . the note be removed or clarified? JSX be purged from the file? adding tests to this file should they be free of JSX? In certain contexts but not others?
Normally, our style is to use jsx within tests. I think some of the tests explicitly aren't using jsx, and that's the point. Perhaps it would be better to copy-paste that message into each of the tests that doesn't use jsx, since it's easy to miss the note up at the top and having the note at the top is somewhat ambiguous.
Thanks for the feedback. Yeah, for both of those reasons I'd say :+1: to either that or splitting it into two files if that made sense to you (would help with the ease of missing it if it's just at the top and make the alternative of repeating it within the file unnecessary): .
I'd be happy to submit a PR for either of these cases!
I think I prefer having the inline comment copy-pasted. A little copy-pasting never hurt anyone (). I'd take a PR for this, assuming no one else objects.

expect(instance.props.fruit).toBe('persimmon'); }); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> it('should normalize props with default values', function() { var Component = React.createClass({ getDefaultProps: function() {


Question:
The have this at the beginning: But there're a number of instances of JSX in the file. For example, . the note be removed or clarified? JSX be purged from the file? adding tests to this file should they be free of JSX? In certain contexts but not others?
Normally, our style is to use jsx within tests. I think some of the tests explicitly aren't using jsx, and that's the point. Perhaps it would be better to copy-paste that message into each of the tests that doesn't use jsx, since it's easy to miss the note up at the top and having the note at the top is somewhat ambiguous.
Thanks for the feedback. Yeah, for both of those reasons I'd say :+1: to either that or splitting it into two files if that made sense to you (would help with the ease of missing it if it's just at the top and make the alternative of repeating it within the file unnecessary): .
I'd be happy to submit a PR for either of these cases!
I think I prefer having the inline comment copy-pasted. A little copy-pasting never hurt anyone (). I'd take a PR for this, assuming no one else objects.

expect(console.error.argsForCall.length).toBe(0); }); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> it('identifies elements, but not JSON, if Symbols are supported', function() { // Rudimentary polyfill // Once all jest engines support Symbols natively we can swap this to test


Question:
(I am using 15rc2 because I need all the svg tags) I am rendering a foreignObject svg tag. According to I put body tag inside that tag and then whatever html I want in there. renderToString on the server leaves the body tag in place, and gives it a react-dataid. However when rendered on the client that body tag is removed. So when I look at the live elements, the body inside foreignObjects is gone, along with it's data-reactid. The server source ( ie view page source ) shows that the body tag was rendered with the missing react-dataid. The result is that you get a “Invariant Violation: Unable to find element with ID XX”, when the page updates, and somethings don't work. Removing the body from inside the foreignObject tag seems to solve the problem, but I don't know if that is an "OK" solution to this or if that body tag is necessary in some scenarios. But in either case this seems to be a scenario where server rendering results in different DOM/HTML then client rendering. Is this a problem, or is the body tag not supposed to there anyway? Todd
We never render the on the client side - only on the server side. Can you provide a jsfiddle that demonstrates the invariant violation?
Thanks for tracking down more specifically. Could be that browsers don't actually support that body usage? Or when actually parsed from markup, the body node doesn't exist (which seems likely and matches up with what we see in other situations where the browser changes markup). I won't have a chance to look into this more for a few days - it might be best to just use your alternate approach for now.
I can remove the body tag. It seems to work ok with out it. Whats clear at this point is that if the server sends the body tag, it is not parsed into a DOM node, at least on mac with Chrome and Safari. That results in the error, since the data-reactid for the body is missing. IE doesn't support foreignObject so its not relevant there. MS Edge does, but I haven't tested it.
It seems so. Even without React, I can’t get Chrome (or Firefox for that matter) to make an actual node: <img width="261" alt="screen shot 2016-03-17 at 15 19 30" src=""
FWIW, does manage to put one in:
Sounds like we should add this to : we should warn and tell you you can't put a body tag inside foreignObject. We don't do anything much for SVG there right now; probably the ideal solution would be to pass the namespace info down too, then we can distinguish SVG and HTML tags with the same name (like title), then make sure the contents of a SVG tag are appropriate HTML tags. Not sure which HTML tags are and aren't allowed but it might be detailed in the HTML5 spec at
Can I take this one?
please do :-)

expect(isTagStackValid(['table', 'tr'])).toBe(false); expect(isTagStackValid(['div', 'ul', 'li', 'div', 'li'])).toBe(false); expect(isTagStackValid(['div', 'html'])).toBe(false); <ins> expect(isTagStackValid(['body', 'body'])).toBe(false); expect(isTagStackValid(['svg', 'foreignObject', 'body', 'p'])).toBe(false); </ins> }); });


Question:
(I am using 15rc2 because I need all the svg tags) I am rendering a foreignObject svg tag. According to I put body tag inside that tag and then whatever html I want in there. renderToString on the server leaves the body tag in place, and gives it a react-dataid. However when rendered on the client that body tag is removed. So when I look at the live elements, the body inside foreignObjects is gone, along with it's data-reactid. The server source ( ie view page source ) shows that the body tag was rendered with the missing react-dataid. The result is that you get a “Invariant Violation: Unable to find element with ID XX”, when the page updates, and somethings don't work. Removing the body from inside the foreignObject tag seems to solve the problem, but I don't know if that is an "OK" solution to this or if that body tag is necessary in some scenarios. But in either case this seems to be a scenario where server rendering results in different DOM/HTML then client rendering. Is this a problem, or is the body tag not supposed to there anyway? Todd
We never render the on the client side - only on the server side. Can you provide a jsfiddle that demonstrates the invariant violation?
Thanks for tracking down more specifically. Could be that browsers don't actually support that body usage? Or when actually parsed from markup, the body node doesn't exist (which seems likely and matches up with what we see in other situations where the browser changes markup). I won't have a chance to look into this more for a few days - it might be best to just use your alternate approach for now.
I can remove the body tag. It seems to work ok with out it. Whats clear at this point is that if the server sends the body tag, it is not parsed into a DOM node, at least on mac with Chrome and Safari. That results in the error, since the data-reactid for the body is missing. IE doesn't support foreignObject so its not relevant there. MS Edge does, but I haven't tested it.
It seems so. Even without React, I can’t get Chrome (or Firefox for that matter) to make an actual node: <img width="261" alt="screen shot 2016-03-17 at 15 19 30" src=""
FWIW, does manage to put one in:
Sounds like we should add this to : we should warn and tell you you can't put a body tag inside foreignObject. We don't do anything much for SVG there right now; probably the ideal solution would be to pass the namespace info down too, then we can distinguish SVG and HTML tags with the same name (like title), then make sure the contents of a SVG tag are appropriate HTML tags. Not sure which HTML tags are and aren't allowed but it might be detailed in the HTML5 spec at
Can I take this one?
please do :-)

case 'rt': return impliedEndTags.indexOf(parentTag) === -1; <ins> case 'body': </ins> case 'caption': case 'col': case 'colgroup':


Question:
Identical app. I call after the app is loaded. React 0.14.7: <img width="622" alt="screen shot 2016-03-17 at 20 31 56" src=""React 15.0 RC1, RC2 and master: <img width="635" alt="screen shot 2016-03-17 at 20 34 02" src=""We should fix this before releasing 15.0.
There seem to be two distinct things causing this issue: is now a possible argument for and points to DOM nodes which now have a hidden field which points to the component instances which point to .. DOM nodes, I guess. now accepts a argument for a better warning which pulls component instances into the which in turn pull nodes which in turn pull components.

} } <ins> function stripComplexValues(key, value) { if (typeof value !== 'object' || Array.isArray(value) || value == null) { return value; } var prototype = Object.getPrototypeOf(value); if (!prototype || prototype === Object.prototype) { return value; } return '<not serializable>'; } </ins> // This implementation of ReactPerf is going away some time mid 15.x. // While we plan to keep most of the API, the actual format of measurements // will change dramatically. To signal this, we wrap them into an opaque-ish


Question:
Identical app. I call after the app is loaded. React 0.14.7: <img width="622" alt="screen shot 2016-03-17 at 20 31 56" src=""React 15.0 RC1, RC2 and master: <img width="635" alt="screen shot 2016-03-17 at 20 34 02" src=""We should fix this before releasing 15.0.
There seem to be two distinct things causing this issue: is now a possible argument for and points to DOM nodes which now have a hidden field which points to the component instances which point to .. DOM nodes, I guess. now accepts a argument for a better warning which pulls component instances into the which in turn pull nodes which in turn pull components.

var result = {}; result[DOMProperty.ID_ATTRIBUTE_NAME] = item.id; result.type = item.type; <del> result.args = JSON.stringify(item.args); </del> <ins> result.args = JSON.stringify(item.args, stripComplexValues); </ins> return result; })); console.log(


Question:
Identical app. I call after the app is loaded. React 0.14.7: <img width="622" alt="screen shot 2016-03-17 at 20 31 56" src=""React 15.0 RC1, RC2 and master: <img width="635" alt="screen shot 2016-03-17 at 20 34 02" src=""We should fix this before releasing 15.0.
There seem to be two distinct things causing this issue: is now a possible argument for and points to DOM nodes which now have a hidden field which points to the component instances which point to .. DOM nodes, I guess. now accepts a argument for a better warning which pulls component instances into the which in turn pull nodes which in turn pull components.

expect(summary).toEqual([]); });  it('should print a table after calling printOperations', function() { var container = document.createElement('div'); var measurements = measure(() => { ReactDOM.render(
hey
, container); }); spyOn(console, 'table'); ReactDefaultPerf.printOperations(measurements); expect(console.table.calls.length).toBe(1); expect(console.table.argsForCall[0][0]).toEqual([{ 'data-reactid': '', type: 'set innerHTML', args: '{"node":"<not serializable>","children":[],"html":null,"text":null}', }]); });  it('warns once when using getMeasurementsSummaryMap', function() { var measurements = measure(() => {}); spyOn(console, 'error');


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

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


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

fakeNativeEvent, node ); <ins> // Since we aren't using pooling, always persist the event. This will make // sure it's marked and won't warn when setting additional properties. event.persist(); </ins> Object.assign(event, eventData); if (dispatchConfig.phasedRegistrationNames) {


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

expect(handler).not.toHaveBeenCalled(); });  it('should not warn when simulating events with extra properties', function() { spyOn(console, 'error'); var CLIENT_X = 100; var Component = React.createClass({ handleClick: function(e) { expect(e.clientX).toBe(CLIENT_X); }, render: function() { return
; }, }); var element = document.createElement('div'); var instance = ReactDOM.render(<Component />, element); ReactTestUtils.Simulate.click( ReactDOM.findDOMNode(instance), {clientX: CLIENT_X} ); expect(console.error.calls.length).toBe(0); });  it('can scry with stateless components involved', function() { var Stateless = () =>

; var SomeComponent = React.createClass({


Question:
has two calls to the Component class construction which are missing use of the 'new' operator. The calls are like this: Component(publicProps, publicContext, updateQueue) and are here: and here:
This is intentional. We check if we need to construct , and then use it to either call or not. This lets us support functional components and factory components:

var args = [ "bin/jsx", <ins> "--cache-dir", ".module-cache", </ins> config.sourceDir, config.outputDir ];


Question:
Do you want to request a feature or report a bug? This is more of a documentation discussion What is the current behavior? Currently, the contributing guide lists the lint step before running prettier. For example, says: 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: ). What is the expected behavior? I think it would make more sense to run prettier first, since it can automatically get rid of certain lint errors (like single-quotes or comma-dangle). A first-time contributor following the steps in order might waste time fixing things manually at the lint step before proceeding to the formatting step. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? N/A
Happy to take PR fixing it.
Thanks to reminding, I make a PR for it.
Seems like this was fixed.

2. If you've added code that should be tested, add tests! 3. If you've changed APIs, update the documentation. 4. Ensure the test suite passes (`npm test`). <del> 5. Make sure your code lints (`npm run lint`). 6. Format your code with [prettier](https://github.com/prettier/prettier) (`npm run prettier`). </del> <ins> 5. Format your code with [prettier](https://github.com/prettier/prettier) (`npm run prettier`). 6. Make sure your code lints (`npm run lint`). </ins> 7. Run the [Flow](https://flowtype.org/) typechecks (`npm run flow`). 8. If you added or removed any tests, run `./scripts/fiber/record-tests` before submitting the pull request, and commit the resulting changes. 9. If you haven't already, complete the CLA.


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

var invariant = require('fbjs/lib/invariant'); var ExecutionEnvironment = require('fbjs/lib/ExecutionEnvironment'); <del> // TODO: There's no way to cancel these, because Fiber doesn't atm. let rAF: (callback: (time: number) => void) => number; </del> <ins> // TODO: There's no way to cancel, because Fiber doesn't atm. </ins> let rIC: (callback: (deadline: Deadline) => void) => number; if (!ExecutionEnvironment.canUseDOM) { <del> rAF = function(frameCallback: (time: number) => void): number { setTimeout(frameCallback, 16); return 0; }; </del> rIC = function(frameCallback: (deadline: Deadline) => void): number { setTimeout(() => { frameCallback({


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

'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;


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

isIdleScheduled = false; var callback = scheduledRICCallback; scheduledRICCallback = null; <del> if (callback) { </del> <ins> if (callback !== null) { </ins> callback(frameDeadlineObject); } };


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

} var callback = scheduledRAFCallback; scheduledRAFCallback = null; <del> if (callback) { </del> <ins> if (callback !== null) { </ins> callback(rafTime); } }; <del> rAF = function(callback: (time: number) => void): number { // This assumes that we only schedule one callback at a time because that's // how Fiber uses it. scheduledRAFCallback = callback; if (!isAnimationFrameScheduled) { // If rIC didn't already schedule one, we need to schedule a frame. isAnimationFrameScheduled = true; requestAnimationFrame(animationTick); } return 0; }; </del> rIC = function(callback: (deadline: Deadline) => void): number { // This assumes that we only schedule one callback at a time because that's // how Fiber uses it.


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

return 0; }; } else { <del> rAF = requestAnimationFrame; </del> rIC = requestIdleCallback; } <del> exports.rAF = rAF; </del> exports.rIC = rIC;


Question: Do you want to request a feature or report a bug? bug What is the current behavior? In the render Fragments example, the JSX tag is closed prematurely. 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: ). — What is the expected behavior? Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.0.0 documentation website on Chrome Android. Previously array Fragments weren't supported.

```javascript render() { return [ <del> <li key="A"/>First item</li>, <li key="B"/>Second item</li>, <li key="C"/>Third item</li>, </del> <ins> <li key="A">First item</li>, <li key="B">Second item</li>, <li key="C">Third item</li>, </ins> ]; } ```


Question:
The current default behavior is that keyboard users will get to the code sections of the live editor and get stuck. Can someone configure ignoreTabKey which makes the editor ignore tab key presses so that keyboard users can tab past the editor without getting stuck? Chrome on Windows atm and cannot edit it to submit a fix. Sorry about that :(
Thanks for bringing this to our attention

}, }} className="gatsby-highlight"> <del> <LiveEditor onChange={this._onChange} /> </del> <ins> <LiveEditor onChange={this._onChange} ignoreTabKey={true} /> </ins> </div> </div> {error &&


Question:
Do you want to request a feature or report a bug? Improvement What is the current behavior?  does not currently support the property. () is nice to have when you want to write key-specific handling—rather than input-specific (dependent on layout and modifier keys) handling. What is the expected behavior? already exposes a property. It should have a property as well. Currently, if you want to use the 's , you must access it through 's . Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Affects React 16 and earlier (I assume).
I created the PR for this.
the above PR is stale and closed; should I pick this up? planning to replicate the same and follow the PR suggestions; any tips or idea?
Can you give me an idea of how widely supported it is?
According to it is supported in all major desktop browsers. Are there any plans to implement this? I am not sure whether I should mark it with until this issue is resolved or don't use it at all.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!

function getUnboundedScrollPosition(scrollable) { if (scrollable === window) { return { <del> x: document.documentElement.scrollLeft || document.body.scrollLeft, y: document.documentElement.scrollTop  || document.body.scrollTop </del> <ins> x: window.pageXOffset || document.documentElement.scrollLeft, y: window.pageYOffset || document.documentElement.scrollTop </ins> }; } return {


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? bug What is the current behavior? <!-- 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: --The change seems to have broken the server-side rendering on : I'm attempting to the to test and getting the following error from the server-side when I load the page: It points to this line: What is the expected behavior? No ReferenceError in server-side environment. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? (not published at the time of writing) Node environment: during server-side rendering in response to a browser request.
fixed in

import requestAnimationFrameForReact from 'shared/requestAnimationFrameForReact'; import ExecutionEnvironment from 'fbjs/lib/ExecutionEnvironment'; <ins> import invariant from 'fbjs/lib/invariant'; import warning from 'fbjs/lib/warning'; </ins> // We capture a local reference to any global, in case it gets polyfilled after // this module is initially evaluated.


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? bug What is the current behavior? <!-- 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: --The change seems to have broken the server-side rendering on : I'm attempting to the to test and getting the following error from the server-side when I load the page: It points to this line: What is the expected behavior? No ReferenceError in server-side environment. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? (not published at the time of writing) Node environment: during server-side rendering in response to a browser request.
fixed in

localClearTimeout(timeoutId); }; } else { <ins> if (__DEV__) { if (typeof requestAnimationFrameForReact !== 'function') { warning( false, 'React depends on requestAnimationFrame. Make sure that you load a ' + 'polyfill in older browsers. https://fb.me/react-polyfills', ); } } let localRequestAnimationFrame = typeof requestAnimationFrameForReact === 'function' ? requestAnimationFrameForReact : function(callback: Function) { invariant( false, 'React depends on requestAnimationFrame. Make sure that you load a ' + 'polyfill in older browsers. https://fb.me/react-polyfills', ); }; </ins> let headOfPendingCallbacksLinkedList: CallbackConfigType | null = null; let tailOfPendingCallbacksLinkedList: CallbackConfigType | null = null;


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? bug What is the current behavior? <!-- 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: --The change seems to have broken the server-side rendering on : I'm attempting to the to test and getting the following error from the server-side when I load the page: It points to this line: What is the expected behavior? No ReferenceError in server-side environment. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? (not published at the time of writing) Node environment: during server-side rendering in response to a browser request.
fixed in

if (!isAnimationFrameScheduled) { // Schedule another animation callback so we retry later. isAnimationFrameScheduled = true; <del> requestAnimationFrameForReact(animationTick); </del> <ins> localRequestAnimationFrame(animationTick); </ins> } } };


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? bug What is the current behavior? <!-- 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: --The change seems to have broken the server-side rendering on : I'm attempting to the to test and getting the following error from the server-side when I load the page: It points to this line: What is the expected behavior? No ReferenceError in server-side environment. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? (not published at the time of writing) Node environment: during server-side rendering in response to a browser request.
fixed in

// might want to still have setTimeout trigger scheduleWork as a backup to ensure // that we keep performing work. isAnimationFrameScheduled = true; <del> requestAnimationFrameForReact(animationTick); </del> <ins> localRequestAnimationFrame(animationTick); </ins> } return scheduledCallbackConfig; };


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? bug What is the current behavior? <!-- 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: --The change seems to have broken the server-side rendering on : I'm attempting to the to test and getting the following error from the server-side when I load the page: It points to this line: What is the expected behavior? No ReferenceError in server-side environment. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? (not published at the time of writing) Node environment: during server-side rendering in response to a browser request.
fixed in

'use strict'; <del> import ExecutionEnvironment from 'fbjs/lib/ExecutionEnvironment'; import warning from 'fbjs/lib/warning'; </del> // We capture a local reference to any global, in case it gets polyfilled after // this module is initially evaluated. // We want to be using a consistent implementation. <del> const localRequestAnimationFrame = requestAnimationFrame; </del> <ins> const localRequestAnimationFrame = typeof requestAnimationFrame === 'function' ? requestAnimationFrame : undefined; </ins> <del> if (__DEV__) { if ( ExecutionEnvironment.canUseDOM && typeof localRequestAnimationFrame !== 'function' ) { warning( false, 'React depends on requestAnimationFrame. Make sure that you load a ' + 'polyfill in older browsers. https://fb.me/react-polyfills', ); } } </del> <ins> // The callsites should check if the requestAnimationFrame imported from this module is a function, // fire a developer warning if it doesn't exist, and substitute it by a shim in that case // (e.g. that throws on call). </ins> export default localRequestAnimationFrame;


Question:
Do you want to request a feature or report a bug? Bug (for electron users) What is the current behavior? When running jest, if any components containing a webview element are rendered, a warning is rendered to the console. When many tests are run, the output is littered with warnings. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: What is the expected behavior? No warning is logged to the console. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React: 16.4.1 Electron: 2.0.6 Unknown if it worked in prior versions of react.
What other special tags does Electron have?
Looking through their docs it seems to be only the tag for now:
In that case I don’t mind adding it to the whitelist. Send a PR?
You beat me to the punch. Thanks so much and

time: true, // There are working polyfills for <dialog>. Let people use it. dialog: true, <ins> // Electron ships a custom <webview> tag to display external web content in // an isolated frame and process. // This tag is not present in non Electron environments such as JSDom which // is often used for testing purposes. // @see https://electronjs.org/docs/api/webview-tag webview: true, </ins> }; validatePropertiesInDevelopment = function(type, props) {


Question: With this: If I render again after it resolves, it won't get the default prop value. This is a bug.

): null | Fiber { if (current === null) { let type = Component.type; <del> if (isSimpleFunctionComponent(type) && Component.compare === null) { </del> <ins> if ( isSimpleFunctionComponent(type) && Component.compare === null && // SimpleMemoComponent codepath doesn't resolve outer props either. Component.defaultProps === undefined ) { </ins> // If this is a plain function component without default props, // and with only the default shallow comparison, we upgrade it // to a SimpleMemoComponent to allow fast path updates.


Question: With this: If I render again after it resolves, it won't get the default prop value. This is a bug.

case MemoComponent: { const type = workInProgress.type; const unresolvedProps = workInProgress.pendingProps; <del> const resolvedProps = resolveDefaultProps(type.type, unresolvedProps); </del> <ins> // Resolve outer props first, then resolve inner props. let resolvedProps = resolveDefaultProps(type, unresolvedProps); resolvedProps = resolveDefaultProps(type.type, resolvedProps); </ins> return updateMemoComponent( current, workInProgress,


Question: With this: If I render again after it resolves, it won't get the default prop value. This is a bug.

expect(root).toMatchRenderedOutput('FooBar'); expect(ref.current).not.toBe(null); }); <ins> // Regression test for #14310 it('supports defaultProps defined on the memo() return value', async () => { const Add = React.memo(props => { return props.inner + props.outer; }); Add.defaultProps = { inner: 2, }; const LazyAdd = lazy(() => fakeImport(Add)); const root = ReactTestRenderer.create( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={2} /> </Suspense>, { unstable_isConcurrent: true, }, ); expect(root).toFlushAndYield(['Loading...']); expect(root).toMatchRenderedOutput(null); // Mount await Promise.resolve(); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('4'); // Update (shallowly equal) root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={2} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('4'); // Update root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={3} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('5'); // Update (shallowly equal) root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={3} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('5'); // Update (explicit props) root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={1} inner={1} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('2'); // Update (explicit props, shallowly equal) root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={1} inner={1} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('2'); // Update root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={1} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('3'); }); it('merges defaultProps in the correct order', async () => { let Add = React.memo(props => { return props.inner + props.outer; }); Add.defaultProps = { inner: 100, }; Add = React.memo(Add); Add.defaultProps = { inner: 2, outer: 0, }; const LazyAdd = lazy(() => fakeImport(Add)); const root = ReactTestRenderer.create( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={2} /> </Suspense>, { unstable_isConcurrent: true, }, ); expect(root).toFlushAndYield(['Loading...']); expect(root).toMatchRenderedOutput(null); // Mount await Promise.resolve(); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('4'); // Update root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={3} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('5'); // Update root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('2'); }); </ins> });


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? when typing in a controlled input, the cursor always jumps to the end. This was an old issue that seems to have resurfaced. used in the docs has the problem in all browsers as far as I have been able to test. What is the expected behavior? because we are using the state to update the component as soon as it's changed, the input element should be able to keep the cursor in the same place. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? I'm at latest (16.8.2) and I tested on Chrome, FireFox, and Edge on Windows as far as I know, this was working at some point, though I don't know how long ago. possibly even before "Fiber"
This is quite weird. Same code works for me on CodeSandbox: Not sure what's going on here.
Seems UMD-specific.
Thank you very much for reporting this. It's a serious regression in the last patch release, and exposed some lacking coverage in our test suite regarding UMD bundles. I have a fix ready in
Great! thank you for the fix.
This is fixed in 16.8.3. Unfortunately unpkg doesn't seem to pick up the 16.8.3 version yet from its default redirect.
That's OK, I replaced the resources with the specific release artifacts to test and it works great now.
it flipped for me and I'm actually having the same problem OP reported in your CodeSandbox, but not in his codepen. Should that be? Chrome 74
I've updated from react 16.8.1 to 16.8.6. Still having the same problem...
I am running into this same issue. I have created the following fiddle which is a boiled down version of what I have. Ultimately once the event stack finishes it appears that React clears the value in the input since it is controlled. Then when the timeout fires it sets the correct value but at this time the position is lost. I tried the fix this by handling the state internally to the TestInput Component as in the following fiddle. But after debugging it appears that setState causes getDerivedStateFromProps to be called which has the old value and I end up in the same mess. I feel I need getDerivedStateFromProps because I have handle the case where the value can change externally and I need to set the state to this new value. I believe if getDerivedStateFromProps was NOT called for a setState change then perhaps this problem would not exist, at least for my second example. But I am not familiar with the internals of React to even feel confident in this suggestion, so please take it with a grain of salt of course.
Okay based on my second fiddle I have come up with the following solution which should not require weird cursor manipulation. Please review, test, and use at your discretion. I have tested it a little and it appears to work. If I run into any problems I will post here.
Is this issue fixed? I'm having the same problem in 16.8.6.
Here is how I reproduce this issue. Is there something I'm doing wrong (or should do differently)?
There are 2 possible ways to get around this issue, as far as I can tell. Solution 1: Use the from the prop. Solution 2: Update the local state simultaneously as the parent state.
You're round-tripping the value change from to and back to and then calling . Apparently this round-trip makes React forget/reset the cursor position because I assume it looses a association between value and input element and/or re-renders the whole component. suggested in to call directly in the component which does work, but is not ideal when one prefers a stateless component. What I've done to workaround is to make the uncontrolled (change to ) with a prop. This also brings the benefit of the input remaining responsive when is computationally expensive.
In your example if you make a change, the InputChild component will be rendered once with outdated values. This is because the new value isn't set until useEffect. So whatever you typed will be erased for one frame, then put back after useEffect. This is enough to make the cursor position ambiguous to the browser. As a hack suggestion, you can swap useEffect with useMemo. This works because useMemo runs before render.

unstable_continueExecution, unstable_wrapCallback, unstable_getCurrentPriorityLevel, <ins> unstable_IdlePriority, unstable_ImmediatePriority, unstable_LowPriority, unstable_NormalPriority, unstable_UserBlockingPriority, </ins> } from 'scheduler'; import { __interactionsRef,


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? when typing in a controlled input, the cursor always jumps to the end. This was an old issue that seems to have resurfaced. used in the docs has the problem in all browsers as far as I have been able to test. What is the expected behavior? because we are using the state to update the component as soon as it's changed, the input element should be able to keep the cursor in the same place. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? I'm at latest (16.8.2) and I tested on Chrome, FireFox, and Edge on Windows as far as I know, this was working at some point, though I don't know how long ago. possibly even before "Fiber"
This is quite weird. Same code works for me on CodeSandbox: Not sure what's going on here.
Seems UMD-specific.
Thank you very much for reporting this. It's a serious regression in the last patch release, and exposed some lacking coverage in our test suite regarding UMD bundles. I have a fix ready in
Great! thank you for the fix.
This is fixed in 16.8.3. Unfortunately unpkg doesn't seem to pick up the 16.8.3 version yet from its default redirect.
That's OK, I replaced the resources with the specific release artifacts to test and it works great now.
it flipped for me and I'm actually having the same problem OP reported in your CodeSandbox, but not in his codepen. Should that be? Chrome 74
I've updated from react 16.8.1 to 16.8.6. Still having the same problem...
I am running into this same issue. I have created the following fiddle which is a boiled down version of what I have. Ultimately once the event stack finishes it appears that React clears the value in the input since it is controlled. Then when the timeout fires it sets the correct value but at this time the position is lost. I tried the fix this by handling the state internally to the TestInput Component as in the following fiddle. But after debugging it appears that setState causes getDerivedStateFromProps to be called which has the old value and I end up in the same mess. I feel I need getDerivedStateFromProps because I have handle the case where the value can change externally and I need to set the state to this new value. I believe if getDerivedStateFromProps was NOT called for a setState change then perhaps this problem would not exist, at least for my second example. But I am not familiar with the internals of React to even feel confident in this suggestion, so please take it with a grain of salt of course.
Okay based on my second fiddle I have come up with the following solution which should not require weird cursor manipulation. Please review, test, and use at your discretion. I have tested it a little and it appears to work. If I run into any problems I will post here.
Is this issue fixed? I'm having the same problem in 16.8.6.
Here is how I reproduce this issue. Is there something I'm doing wrong (or should do differently)?
There are 2 possible ways to get around this issue, as far as I can tell. Solution 1: Use the from the prop. Solution 2: Update the local state simultaneously as the parent state.
You're round-tripping the value change from to and back to and then calling . Apparently this round-trip makes React forget/reset the cursor position because I assume it looses a association between value and input element and/or re-renders the whole component. suggested in to call directly in the component which does work, but is not ideal when one prefers a stateless component. What I've done to workaround is to make the uncontrolled (change to ) with a prop. This also brings the benefit of the input remaining responsive when is computationally expensive.
In your example if you make a change, the InputChild component will be rendered once with outdated values. This is because the new value isn't set until useEffect. So whatever you typed will be erased for one frame, then put back after useEffect. This is enough to make the cursor position ambiguous to the browser. As a hack suggestion, you can swap useEffect with useMemo. This works because useMemo runs before render.

unstable_pauseExecution, unstable_continueExecution, unstable_getCurrentPriorityLevel, <ins> unstable_IdlePriority, unstable_ImmediatePriority, unstable_LowPriority, unstable_NormalPriority, unstable_UserBlockingPriority, </ins> }, SchedulerTracing: { __interactionsRef,


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? when typing in a controlled input, the cursor always jumps to the end. This was an old issue that seems to have resurfaced. used in the docs has the problem in all browsers as far as I have been able to test. What is the expected behavior? because we are using the state to update the component as soon as it's changed, the input element should be able to keep the cursor in the same place. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? I'm at latest (16.8.2) and I tested on Chrome, FireFox, and Edge on Windows as far as I know, this was working at some point, though I don't know how long ago. possibly even before "Fiber"
This is quite weird. Same code works for me on CodeSandbox: Not sure what's going on here.
Seems UMD-specific.
Thank you very much for reporting this. It's a serious regression in the last patch release, and exposed some lacking coverage in our test suite regarding UMD bundles. I have a fix ready in
Great! thank you for the fix.
This is fixed in 16.8.3. Unfortunately unpkg doesn't seem to pick up the 16.8.3 version yet from its default redirect.
That's OK, I replaced the resources with the specific release artifacts to test and it works great now.
it flipped for me and I'm actually having the same problem OP reported in your CodeSandbox, but not in his codepen. Should that be? Chrome 74
I've updated from react 16.8.1 to 16.8.6. Still having the same problem...
I am running into this same issue. I have created the following fiddle which is a boiled down version of what I have. Ultimately once the event stack finishes it appears that React clears the value in the input since it is controlled. Then when the timeout fires it sets the correct value but at this time the position is lost. I tried the fix this by handling the state internally to the TestInput Component as in the following fiddle. But after debugging it appears that setState causes getDerivedStateFromProps to be called which has the old value and I end up in the same mess. I feel I need getDerivedStateFromProps because I have handle the case where the value can change externally and I need to set the state to this new value. I believe if getDerivedStateFromProps was NOT called for a setState change then perhaps this problem would not exist, at least for my second example. But I am not familiar with the internals of React to even feel confident in this suggestion, so please take it with a grain of salt of course.
Okay based on my second fiddle I have come up with the following solution which should not require weird cursor manipulation. Please review, test, and use at your discretion. I have tested it a little and it appears to work. If I run into any problems I will post here.
Is this issue fixed? I'm having the same problem in 16.8.6.
Here is how I reproduce this issue. Is there something I'm doing wrong (or should do differently)?
There are 2 possible ways to get around this issue, as far as I can tell. Solution 1: Use the from the prop. Solution 2: Update the local state simultaneously as the parent state.
You're round-tripping the value change from to and back to and then calling . Apparently this round-trip makes React forget/reset the cursor position because I assume it looses a association between value and input element and/or re-renders the whole component. suggested in to call directly in the component which does work, but is not ideal when one prefers a stateless component. What I've done to workaround is to make the uncontrolled (change to ) with a prop. This also brings the benefit of the input remaining responsive when is computationally expensive.
In your example if you make a change, the InputChild component will be rendered once with outdated values. This is because the new value isn't set until useEffect. So whatever you typed will be erased for one frame, then put back after useEffect. This is enough to make the cursor position ambiguous to the browser. As a hack suggestion, you can swap useEffect with useMemo. This works because useMemo runs before render.

unstable_continueExecution: unstable_continueExecution, unstable_pauseExecution: unstable_pauseExecution, unstable_getFirstCallbackNode: unstable_getFirstCallbackNode, <ins> get unstable_IdlePriority() { return global.React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED .Scheduler.unstable_IdlePriority; }, get unstable_ImmediatePriority() { return global.React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED .Scheduler.unstable_ImmediatePriority; }, get unstable_LowPriority() { return global.React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED .Scheduler.unstable_LowPriority; }, get unstable_NormalPriority() { return global.React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED .Scheduler.unstable_NormalPriority; }, get unstable_UserBlockingPriority() { return global.React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED .Scheduler.unstable_UserBlockingPriority; }, </ins> }); });


Question:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? when typing in a controlled input, the cursor always jumps to the end. This was an old issue that seems to have resurfaced. used in the docs has the problem in all browsers as far as I have been able to test. What is the expected behavior? because we are using the state to update the component as soon as it's changed, the input element should be able to keep the cursor in the same place. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? I'm at latest (16.8.2) and I tested on Chrome, FireFox, and Edge on Windows as far as I know, this was working at some point, though I don't know how long ago. possibly even before "Fiber"
This is quite weird. Same code works for me on CodeSandbox: Not sure what's going on here.
Seems UMD-specific.
Thank you very much for reporting this. It's a serious regression in the last patch release, and exposed some lacking coverage in our test suite regarding UMD bundles. I have a fix ready in
Great! thank you for the fix.
This is fixed in 16.8.3. Unfortunately unpkg doesn't seem to pick up the 16.8.3 version yet from its default redirect.
That's OK, I replaced the resources with the specific release artifacts to test and it works great now.
it flipped for me and I'm actually having the same problem OP reported in your CodeSandbox, but not in his codepen. Should that be? Chrome 74
I've updated from react 16.8.1 to 16.8.6. Still having the same problem...
I am running into this same issue. I have created the following fiddle which is a boiled down version of what I have. Ultimately once the event stack finishes it appears that React clears the value in the input since it is controlled. Then when the timeout fires it sets the correct value but at this time the position is lost. I tried the fix this by handling the state internally to the TestInput Component as in the following fiddle. But after debugging it appears that setState causes getDerivedStateFromProps to be called which has the old value and I end up in the same mess. I feel I need getDerivedStateFromProps because I have handle the case where the value can change externally and I need to set the state to this new value. I believe if getDerivedStateFromProps was NOT called for a setState change then perhaps this problem would not exist, at least for my second example. But I am not familiar with the internals of React to even feel confident in this suggestion, so please take it with a grain of salt of course.
Okay based on my second fiddle I have come up with the following solution which should not require weird cursor manipulation. Please review, test, and use at your discretion. I have tested it a little and it appears to work. If I run into any problems I will post here.
Is this issue fixed? I'm having the same problem in 16.8.6.
Here is how I reproduce this issue. Is there something I'm doing wrong (or should do differently)?
There are 2 possible ways to get around this issue, as far as I can tell. Solution 1: Use the from the prop. Solution 2: Update the local state simultaneously as the parent state.
You're round-tripping the value change from to and back to and then calling . Apparently this round-trip makes React forget/reset the cursor position because I assume it looses a association between value and input element and/or re-renders the whole component. suggested in to call directly in the component which does work, but is not ideal when one prefers a stateless component. What I've done to workaround is to make the uncontrolled (change to ) with a prop. This also brings the benefit of the input remaining responsive when is computationally expensive.
In your example if you make a change, the InputChild component will be rendered once with outdated values. This is because the new value isn't set until useEffect. So whatever you typed will be erased for one frame, then put back after useEffect. This is enough to make the cursor position ambiguous to the browser. As a hack suggestion, you can swap useEffect with useMemo. This works because useMemo runs before render.

}); function filterPrivateKeys(name) { <del> // TODO: Figure out how to forward priority levels. return !name.startsWith('_') && !name.endsWith('Priority'); </del> <ins> // Be very careful adding things to this whitelist! // It's easy to introduce bugs by doing it: // https://github.com/facebook/react/issues/14904 switch (name) { case '__interactionsRef': case '__subscriberRef': // Don't forward these. (TODO: why?) return false; default: return true; } </ins> } function validateForwardedAPIs(api, forwardedAPIs) {


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

<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


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

<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 {useEffect} = require('react'); function useCustom() { useEffect(() => { // ... }, []); } module.exports = {useCustom}; </ins>  No newline at end of file


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

expectHookNamesToEqual(hookNames, ['foo', 'bar', 'baz']); }); <del> it('should return null for hooks without names like useEffect', async () => { </del> <ins> it('should skip loading source files for unnamed hooks like useEffect', async () => { </ins> const Component = require('./__source__/__untransformed__/ComponentWithUseEffect') .Component; <ins> // Since this component contains only unnamed hooks, the source code should not even be loaded. fetchMock.mockIf(/.+$/, request => { throw Error(`Unexpected file request for "${request.url}"`); }); </ins> const hookNames = await getHookNamesForComponent(Component); expectHookNamesToEqual(hookNames, []); // No hooks with names }); <ins> it('should skip loading source files for unnamed hooks like useEffect (alternate)', async () => { const Component = require('./__source__/__untransformed__/ComponentWithExternalUseEffect') .Component; fetchMock.mockIf(/.+$/, request => { // Since th custom hook contains only unnamed hooks, the source code should not be loaded. if (request.url.endsWith('useCustom.js')) { throw Error(`Unexpected file request for "${request.url}"`); } return Promise.resolve(requireText(request.url, 'utf8')); }); const hookNames = await getHookNamesForComponent(Component); expectHookNamesToEqual(hookNames, ['count', null]); // No hooks with names }); </ins> it('should parse names for custom hooks', async () => { const Component = require('./__source__/__untransformed__/ComponentWithNamedCustomHooks') .Component;


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

await test( './__source__/__compiled__/external/ComponentWithMultipleHooksPerLine', ); // external source map <del> await test( './__source__/__compiled__/bundle', 'ComponentWithMultipleHooksPerLine', ); // bundle source map </del> <ins> // await test( //   './__source__/__compiled__/bundle', //   'ComponentWithMultipleHooksPerLine', // ); // bundle source map </ins> }); // TODO Inline require (e.g. require("react").useState()) isn't supported yet.


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

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


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

import {enableHookNameParsing} from 'react-devtools-feature-flags'; import LRU from 'lru-cache'; import {SourceMapConsumer} from 'source-map'; <del> import {getHookName, isNonDeclarativePrimitiveHook} from './astUtils'; </del> <ins> import {getHookName} from './astUtils'; </ins> import {areSourceMapsAppliedToErrors} from './ErrorTester'; import {__DEBUG__} from 'react-devtools-shared/src/constants'; import {getHookSourceLocationKey} from 'react-devtools-shared/src/hookNamesCache';


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

const map: HookNames = new Map(); hooksList.map(hook => { <del> // TODO (named hooks) We should probably filter before this point, // otherwise we are loading and parsing source maps and ASTs for nothing. if (isNonDeclarativePrimitiveHook(hook)) { if (__DEBUG__) { console.log('findHookNames() Non declarative primitive hook'); } // Not all hooks have names (e.g. useEffect or useLayoutEffect) return null; } </del> // We already guard against a null HookSource in parseHookNames() const hookSource = ((hook.hookSource: any): HookSource); const fileName = hookSource.fileName;


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

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


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

} } <ins> // Determines whether incoming hook is a primitive hook that gets assigned to variables. function isUnnamedBuiltInHook(hook: HooksNode) { return ['Effect', 'ImperativeHandle', 'LayoutEffect', 'DebugValue'].includes( hook.name, ); } </ins> function updateLruCache( locationKeyToHookSourceData: Map<string, HookSourceData>, ): Promise<*> {


Question:
Run the Next app, open up react dev tools and inspect the Box component, rendered by Every time react-devtools-extensions 23.0- Could not find ID for Fiber "App"
Hey, thanks for reporting this issue, and sorry it's blocking your workflow. Edit: The reason for this issue seems to be that there are multiple instances, and the one that we are using to get the fiber's ID when we inspect doesn't have the App fiber (a recursive owner of Box). We'll look into why this is occurring soon!
Fixed via

}); }); <ins> it('inspecting nested renderers should not throw', async () => { // Ignoring react art warnings spyOn(console, 'error'); const ReactArt = require('react-art'); const ArtSVGMode = require('art/modes/svg'); const ARTCurrentMode = require('art/modes/current'); store.componentFilters = []; ARTCurrentMode.setCurrent(ArtSVGMode); const {Surface, Group} = ReactArt; function Child() { return ( <Surface width={1} height={1}> <Group /> </Surface> ); } function App() { return <Child />; } await utils.actAsync(() => { legacyRender(<App />, document.createElement('div')); }); expect(store).toMatchInlineSnapshot(` [root] ▾ <App> ▾ <Child> ▾ <Surface> <svg> [root] <Group> `); const inspectedElement = await inspectElementAtIndex(4); expect(inspectedElement.owners).toMatchInlineSnapshot(` Array [ Object { "displayName": "Child", "hocDisplayNames": null, "id": 3, "key": null, "type": 5, }, Object { "displayName": "App", "hocDisplayNames": null, "id": 2, "key": null, "type": 5, }, ] `); }); </ins> describe('error boundary', () => { it('can toggle error', async () => { class LocalErrorBoundary extends React.Component<any> {


Question:
Run the Next app, open up react dev tools and inspect the Box component, rendered by Every time react-devtools-extensions 23.0- Could not find ID for Fiber "App"
Hey, thanks for reporting this issue, and sorry it's blocking your workflow. Edit: The reason for this issue seems to be that there are multiple instances, and the one that we are using to get the fiber's ID when we inspect doesn't have the App fiber (a recursive owner of Box). We'll look into why this is occurring soon!
Fixed via

}; } <ins> // Map of one or more Fibers in a pair to their unique id number. // We track both Fibers to support Fast Refresh, // which may forcefully replace one of the pair as part of hot reloading. // In that case it's still important to be able to locate the previous ID during subsequent renders. const fiberToIDMap: Map<Fiber, number> = new Map(); // Map of id to one (arbitrary) Fiber in a pair. // This Map is used to e.g. get the display name for a Fiber or schedule an update, // operations that should be the same whether the current and work-in-progress Fiber is used. const idToArbitraryFiberMap: Map<number, Fiber> = new Map(); </ins> export function attach( hook: DevToolsHook, rendererID: number,


Question:
Run the Next app, open up react dev tools and inspect the Box component, rendered by Every time react-devtools-extensions 23.0- Could not find ID for Fiber "App"
Hey, thanks for reporting this issue, and sorry it's blocking your workflow. Edit: The reason for this issue seems to be that there are multiple instances, and the one that we are using to get the fiber's ID when we inspect doesn't have the App fiber (a recursive owner of Box). We'll look into why this is occurring soon!
Fixed via

} } <del> // Map of one or more Fibers in a pair to their unique id number. // We track both Fibers to support Fast Refresh, // which may forcefully replace one of the pair as part of hot reloading. // In that case it's still important to be able to locate the previous ID during subsequent renders. const fiberToIDMap: Map<Fiber, number> = new Map(); // Map of id to one (arbitrary) Fiber in a pair. // This Map is used to e.g. get the display name for a Fiber or schedule an update, // operations that should be the same whether the current and work-in-progress Fiber is used. const idToArbitraryFiberMap: Map<number, Fiber> = new Map(); </del> // When profiling is supported, we store the latest tree base durations for each Fiber. // This is so that we can quickly capture a snapshot of those values if profiling starts. // If we didn't store these values, we'd have to crawl the tree when profiling started,


Question:
<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: Current main branch the repository from the main branch node and yarn (node version: 16.14.0, yarn version: 1.22.17, JDK version: tried both 11 and 17) yarn yarn build <!-- 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. --Error message : <!-- 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: --No error messages from rollup. Success in yarn build.
If rollup is crashing during the build process, that's a rollup problem.
Yes, that was what my colleagues and I are thinking too. Then shouldn't something change related to Rollup, like going back to the previous version of code, or another way to resolve the error in the react project?
Exactlly it's the problem of Rollup and already fix it two years ago. See
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!

visitor: { CallExpression: function(path, file) { <del> if (file.filename.indexOf('shared/assign') !== -1) { </del> <ins> if (/shared(/|)assign/.test(file.filename)) { </ins> // Don't replace Object.assign if we're transforming shared/assign return; }


Question:
<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: Current main branch the repository from the main branch node and yarn (node version: 16.14.0, yarn version: 1.22.17, JDK version: tried both 11 and 17) yarn yarn build <!-- 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. --Error message : <!-- 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: --No error messages from rollup. Success in yarn build.
If rollup is crashing during the build process, that's a rollup problem.
Yes, that was what my colleagues and I are thinking too. Then shouldn't something change related to Rollup, like going back to the previous version of code, or another way to resolve the error in the react project?
Exactlly it's the problem of Rollup and already fix it two years ago. See
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!

}, MemberExpression: function(path, file) { <del> if (file.filename.indexOf('shared/assign') !== -1) { </del> <ins> if (/shared(/|)assign/.test(file.filename)) { </ins> // Don't replace Object.assign if we're transforming shared/assign return; }


Question:
When trying to build the [(]) locally: react yarn build-for-devtools from the root repo node version: v16.16.0.
This is the result of :
Yarn is the package manager of choice in this repository. Did you run from the root first?
I did not do that as I dont usually work with yarn. I will try now. Please reject my bug and thanks for your time. I feel a bit stupid.
Im trying it now, and it looks like its working. It would be great if someone adds this to the readme of the extension repo.
Sorry to hear. We definitely want to avoid that. You're absolutely right. I'm on it.
Please note also that they ask to do: . The command has , which doesnt work for windows and should be replaced by . This is the command:

1 Note that at this time, an _experimental_ build is required because DevTools depends on the `createRoot` API.  To install all necessary dependencies, run the following command from the root of the repository: ```sh yarn install ```  #### Build from source To build dependencies from source, run the following command from the root of the repository: ```sh