Question: expect(element.props).toEqual(expectation); }); <ins> it('should warn when `key` is being accessed', function() { spyOn(console, 'error'); var container = document.createElement('div'); var Child = React.createClass({ render: function() { return <div> {this.props.key} </div>; }, }); var Parent = React.createClass({ render: function() { return ( <div> <Child key="0" /> <Child key="1" /> <Child key="2" /> </div> ); }, }); expect(console.error.calls.length).toBe(0); ReactDOM.render(<Parent />, container); expect(console.error.calls.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'Child: `key` is not a prop. Trying to access it will result ' + 'in `undefined` being returned. If you need to access the same ' + 'value within the child component, you should pass it as a different ' + 'prop. (https://fb.me/react-special-props)' ); }); it('should warn when `ref` is being accessed', function() { spyOn(console, 'error'); var container = document.createElement('div'); var Child = React.createClass({ render: function() { return <div> {this.props.ref} </div>; }, }); var Parent = React.createClass({ render: function() { return ( <div> <Child ref="childElement" /> </div> ); }, }); expect(console.error.calls.length).toBe(0); ReactDOM.render(<Parent />, container); expect(console.error.calls.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'Child: `ref` is not a prop. Trying to access it will result ' + 'in `undefined` being returned. If you need to access the same ' + 'value within the child component, you should pass it as a different ' + 'prop. (https://fb.me/react-special-props)' ); }); </ins> it('allows a string to be passed as the type', function() { var element = React.createFactory('div')(); expect(element.type).toBe('div');

The props and are reserved by React, and used internally. Component authors may attempt to access these properties (thinking they could read the value, as per ). We could use (in dev mode) to warn if or is accessed, and point the user to a note/discussion somewhere. That way, users who actually run into the issue will always get a timely message that sends them directly to the relevant explanation/discussion. This would be a good first bug, if we decide we actually want to do it.
This sounds like a great idea to me!
Yeah this seems reasonable.
hi, I am interested in working on this; as I am looking forward to contribute. Kindly show me the way. Thanks in advance!
Take a look at , that should give you a good start and a good idea of what we would be looking for.
Thanks Checking it out right away.
I have taken a look at the pull request, and associated code review comments. It seems the warn-once policy is required here, as implemented in I am not sure I fully understand how this module achieves this, so I am reading it now. As per the code review comments in , I am using the URLs instead of StackOverflow URLs. But the comments over there also mentioned that the PR might break some test cases. I am not sure about the edge cases here. I feel like I could use some help on understanding this. Instead of using GitHub issue comments, is it possible to use some chat-platform such as IRC or slack room or Gitter?
The module achieves deduplication by setting a boolean if it has already warned. The comments about breaking tests are referring to the failing unit tests. Just run and to verify that everything is working before pushing your changes. There are many places where you can discuss, including the IRC channel and/or reactiflux. There are also github issues (which is what our core team predominantly uses), as well as several other channels. The community is pretty big, but nothing is quite as good as reading through the code and github issues, IMHO.
Sorry, I was away. is ready to be reviewed.


Question: } .example-enter.example-enter-active { <del> opacity: 0.99; </del> <ins> opacity: 1; </ins> } ```

Hello, Today I have spotted the bug(?) in IE10/IE11: while setting the inner HTML on any element (, , ) using property the browser will raise an error . I use this with SSR, but the actual HTML received from the server is good, so probably there's a problem with func. Some code: where is some string that contains HTML. !
Hey! This was fixed in and is a known issue. A fix should be out in the next release. However thank you for the great write up!
React has been released. Please update , , and (if you use it) to this version and let us know if it solved the issue! We’d appreciate if you could test before Monday when we plan to get out.
Hi Dan, everything is working now, thank you!


Question:
var tableWrap = [1, '
', '
']; var trWrap = [3, '

', '

'];  var svgWrap = [1, '<svg>', '</svg>'];   var svgWrap = [1, '<svg xmlns="http://www.w3.org/2000/svg">', '</svg>'];  var markupWrap = { '*': [1, '?
', '
'],

Consider the following code: The first line is rendered in but the second one in . If you skip the first rendering it works.
Apparently, doesn't work with svg.
Or, maybe, I'd say that does not work as expected. I see it gets markup and it gets wrap and it creates nodes via like this: but for some reason of that is .
cc This wouldn't work with the context scenario. Maybe separate renderers are need at the top level? Or at least a flag.
what do you mean by 'context scenario'? Or separate renderers at the top level?
Sorry that was directed to based on a conversation I had with him yesterday
I thought you're referring to my PR and pinging Do you have any comments about my PR? In particular, where should I put tests?
It works if ReactMount supplies the context. Are you using XHTML? I was under the impression that in HTML, just an tag with no explicit namespace should work fine.
correct, I'm using xhtml (that's because in my svg there are foreign namespaces and they are ignored in html). I can test if my example works in pure html but I suppose that you might be right.
What about ambiguous elements like? This doesn't have a context to be picked up.
I assumed we'd look at the namespace of the container. Sorry for not being more precise.


Question: const sigCallID = path.scope.generateUidIdentifier('_s'); path.scope.parent.push({ id: sigCallID, <del> init: t.callExpression(t.identifier('$RefreshSig$'), []), </del> <ins> init: t.callExpression(refreshSig, []), </ins> }); // The signature call is split in two parts. One part is called inside the function.

Do you want to request a feature or report a bug? Feature Right now babel plugin emits globals: It would be nice to have them configurable. That would allow to use in environments like SystemJS and have simpler implementation: If you don't mind I could create PR with changes to react-refresh/babel next week. environment:
Happy to take a PR.


Question: injectedMixins.forEach(mixSpecIntoComponent.bind(null, Constructor)); <del> mixSpecIntoComponent(Constructor, IsMountedMixin); </del> <ins> mixSpecIntoComponent(Constructor, IsMountedPreMixin); </ins> mixSpecIntoComponent(Constructor, spec); <ins> mixSpecIntoComponent(Constructor, IsMountedPostMixin); </ins> // Initialize the defaultProps property after all mixins have been merged. if (Constructor.getDefaultProps) {

Do you want to request a feature or report a bug? Bug What is the current behavior? Calling in in prior versions would return . Now it returns . I believe this was untested behavior before, but the new tests that were may check the wrong value: Changing this line to test for will exhibit the behavior. The fix would be to defer setting the flag to until after all mixins and the method were called on the component. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? and anything using is broken. Working correctly in 15.4.x with .
I fixed this locally by splitting the IsMountedMixin into two: Then installing the Post after the spec has been mixed in: For the life of me I can't find the right repo to PR this against though.
This should be fixed with . Can you please verify?
I don't see that version published yet.
It's not set to (still an RC) but it exists: Will turn into 15.6.0 tomorrow.
Ah indeed. It's probably our internal registry being slow. I'll try it out soon.
Confirmed working correctly in .
Great. Thanks for sending the fix!


Question: render: function() { return <div> <Inner /> <ins> Text </ins> </div>; } });

Logging and reveals: Which doesn't make sense (to me at least).
Can you log the too and something to distinguish the two renderComponent calls?
Updated, that makes more sense,


Question: invariant( typeof callback === 'function', 'enqueueCallback(...): You called `setProps`, `replaceProps`, ' + <del> '`setState`, `replaceState`, or `forceUpdate` with a callback that ' + 'isn't callable.' </del> <ins> '`setState`, `replaceState`, or `forceUpdate` with a callback of type ' + '%s. A function is expected', typeof callback === 'object' && Object.keys(callback).length && Object.keys(callback).length < 20 ? typeof callback + ' (keys: ' + Object.keys(callback) + ')' : typeof callback </ins> ); var internalInstance = getInternalInstanceReadyForUpdate(publicInstance);

Oddly enough, the two examples below are not equal as I thought they would be. The error is as follows: I'm assuming that is because the function as assuming an optional callback. But I would expect your code to do a typeof check, and not just a defined check. Can we change it to do a check? I can submit a PR.
Well, the typecheck happens with that exact typecheck, just not directly in forceupdate. Here's forceUpdate: and where the invariant happens: FWIW, is not the same as due to an important distinction. The former makes a new function that is bound but it will pass along any arguments. The latter also is a new function but it explicitly doesn't pass any arguments. So the former gets the event passed along while the latter just drops it. The event isn't callable, thus the invariant. We need to do the typecheck so I guess we could discuss whether we keep it as an invariant or a warning. But it is a misuse of the API.
To follow up on that, the more "equal" thing would be: Which should throw the same error that you see with your first bind example.
Correct. Yes, I understand all of that. It wasn't toooo hard for me to understand what is happening. And it is a misuse of the API. So I guess, I would consider adding the argument type to the invariant to help make it clearer? Something more like: It's kind of moot. But It confused me for a second. Might confuse others also.


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

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


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

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


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

Describe what you were doing when the bug occurred: Please do not remove the text below this line DevTools version: 4.11.0- Call stack: at chrome- at Map.forEach (<anonymous) at RankedChartBuildergetChartData (chrome-) at ProfilingCacheProfilingCache.getRankedChartData (chrome-) at CommitRankedAutoSizer (chrome-) at Rh (chrome-) at Ci (chrome-) at uk (chrome-) at tk (chrome-) at qk (chrome-) Component stack: at CommitRankedAutoSizer (chrome-) at div at div at div at SettingsModalContextController (chrome-) at ProfilerProfiler (chrome-) at ErrorBoundaryErrorBoundary (chrome-) at PortaledContent (chrome-) at div at div at ProfilerContextController (chrome-) at TreeContextController (chrome-) at SettingsContextController (chrome-) at ModalDialogContextController (chrome-) at DevTools_DevTools (chrome-)
It doesn't look like this bug report has enough info for one of us to reproduce it. Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. Screenshots or videos can also be helpful if they help provide context on how to repro the bug. Here are some tips for providing a minimal example:
Just saw this same stacktrace running devtools . I don't know how to reproduce it, so I'm not gonna open a new issue. Call stack: Component call stack: My id was 397.
The only thing I was doing was hitting right arrow key on this thingy to scroll through my rerenders. !
Ah! (sorry to triple post!) I can reproduce it most of the time by clicking on items in the high thirties for this profile:

Describe what you were doing when the bug occurred: on commits greater than 3s through the commits doing a next next Please do not remove the text below this line DevTools version: 4.10.1- Call stack: at updateTree (chrome-) at getCommitTree (chrome-) at ProfilingCacheProfilingCache.getCommitTree (chrome-) at CommitFlamegraphAutoSizer (chrome-) at Hh (chrome-) at qi (chrome-) at mk (chrome-) at lk (chrome-) at kk (chrome-) at ck (chrome-) Component stack: at CommitFlamegraphAutoSizer (chrome-) at div at div at div at SettingsModalContextController (chrome-) at ProfilerProfiler (chrome-) at ErrorBoundaryErrorBoundary (chrome-) at PortaledContent (chrome-) at div at div at ProfilerContextController (chrome-) at TreeContextController (chrome-) at SettingsContextController (chrome-) at ModalDialogContextController (chrome-) at DevToolsDevTools (chrome-)
Can you reliably reproduce this? If so, can you please share a repro case with us? (The bug is unlikely to be fixed without out.)
Should I be providing the profiler json? Because using a recording profiler json or the use case, I mentioned above, it reproduces always. Or are you looking for a repository where this can be reproduced?
Ah, sorry my original request was unclear. No, profiler JSON would likely just show that an element is indeed missing. A repro case (where I can run the code, see where/how/why DevTools misses the element) is what I need to fix.
Argh. So this is going to sound weird. I have a project where I can reproduce this, and I can do that always (see the date @ screenshot) but I can't ship it out due to a lot of internal tooling. So, I tried a similar use-case in my and I cannot it reproduce in that . I'll try some more and see if I can reproduce it in my personal project. The image below is from the project which I can't ship !
I would be willing to sign an NDA or similar agreement if that would help. Otherwise, it would be super helpful if you were able to reduce it to something that you could ship. (Maybe you could start with your full app and remove things until you get to the smallest case that repros the bug?

Then you could share just that?)
Friendly ping. Any update or chance of one?
Hey try the below: Use this repo . The movie attached should help w/ repro steps. I also left some silly comments in - if you wanna try those out as well (somehow I feel they contribute to this trace - I could be wrong there). I haven't experimented much w/ the different yarn, node and npm versions, but below the ones which kinda did it. https://user-
Thank you for the repro! Holiday time so I might not take a look right away, but I'll try to look soonish.
I knew there will be so many edge cases for these unfound fiber errors Anyway, based on repro, the problem (for this case) is that there's a error thrown I think by the recursive function due to the big number of elements that it needs to mount. I reproduced it in . Here's the steps to reproduce it: profiling Show button Hide button profiling
That's good insight. Can confirm this on my side as well, (though only if I disable the host component filter). My intuition when writing DevTools was that it would be very uncommon for apps to have React trees deep or wide enough that the recursive function (or similar functions, e.g. ) would run out of stack. I think that's true, but given how large the user base is I guess it makes sense that it happens sometimes. I took a stab at rewriting the recursive methods in the backend/renderer in but didn't get them all (, , , ) because it would have been a big change and would make the code harder to read. Maybe worth picking back up and finishing that effort. Anyone interested? The good news is, DevTools has decent unit test coverage.
Hi I may not be able to start till next week, but I'd like to give it a shot if you're cool with it
Sounds great Keep me posted.
Friendly ping on this. Had the same issue multiple times and fallback to console log debugging
Circling back around to this. Using the excellent repro steps () shared by I can repro this faster if I change the default items (in ) from to .

Then just loading the app, I notice the following error (in the console): If I ignore this error and profile anyway: the number of list items from 5,000 -0 several errors (in the DevTools extension console, likely caused by the stack overflow above): profiling an error now in DevTools UI (related to the previous errors): So the underlying cause here, as pointed out by is the original stack overflow error.
Converting all of the recursive methods in DevTools to be iterative would be a bit lift but I think I can fix this particular case by iterating over siblings rather than recursing. I'll post a PR shortly.


Question: topLevelTypes.topContextMenu, topLevelTypes.topFocus, topLevelTypes.topKeyDown, <ins> topLevelTypes.topKeyUp, </ins> topLevelTypes.topMouseDown, topLevelTypes.topMouseUp, topLevelTypes.topSelectionChange,

Do you want to request a feature or report a bug? Bug. What is the current behavior? Right now, React provides a cross-browser workaround for the event. , so React hacks around this by evaluating the selection after both and , which is smart! However, if you haven't an handler to your component, the part of the selection listening hack for Firefox won't ever fire. Which means if you happen to be doing something in that changes the selection, it won't be caught by as expected, such that the next time fires, the handler will be triggered (via the part of the hack), since React thinks the selection has changed. Example: You place your cursor at the end of a sentence. fires thanks to . updates the selection. You the last character: you handle deleting the character, and preventing default. doesn't fire, because on change hasn't taken place yet, as expected. updates the selection. You another character: you handle deleting another character. fires thanks to , but its internal state is comparing it to the selection before it was updated by , so it is out of date. Not expected. If you add a noop handler for , this problem goes away, since will always fire after rendering thanks to , and then it will never fire incorrectly due to . An example is in , actually doesn't do anything. Except without, the handling wouldn't stay in sync in Firefox. What is the expected behavior? Ideally I'd think that the event hack would still fire even without having to have the developer add a noop to their component? Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 15 in Firefox.
Thanks for the detailed report Sorry I didn't get to this until now. This should be an easy fix – just adding onKeyUp below onKeyDown here:


Question: var isInputEventSupported = false; if (ExecutionEnvironment.canUseDOM) { // IE9 claims to support the input event but fails to trigger it when <del> // deleting text, so we ignore its input events </del> <ins> // deleting text, so we ignore its input events. // IE10+ fire input events to often, such when a placeholder // changes or when an input with a placeholder is focused. </ins> isInputEventSupported = isEventSupported('input') && ( <del> !('documentMode' in document) || document.documentMode > 9 </del> <ins> !('documentMode' in document) || document.documentMode > 11 </ins> ); } /** <del> * (For old IE.) Replacement getter/setter for the `value` property that gets </del> <ins> * (For IE <=11) Replacement getter/setter for the `value` property that gets </ins> * set on the active element. */ var newValueProp = {

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

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


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

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.


Question: window.devtools = devtools; window.server = devtools .setContentDOMNode(document.getElementById("container")) <ins> .setDisconnectedCallback(attachListeners) </ins> .setStatusListener(function(status) { const element = document.getElementById("loading-status"); if (element) {

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


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

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


Question: } } } <ins> if (__DEV__) { // Create dummy `key` and `ref` property to `props` to warn users // against its use if (typeof props.$$typeof === 'undefined' || props.$$typeof !== REACT_ELEMENT_TYPE) { if (!props.hasOwnProperty('key')) { Object.defineProperty(props, 'key', { get: function() { if (!specialPropKeyWarningShown) { specialPropKeyWarningShown = true; warning( false, '%s: `key` is not a prop. Trying to access it will result ' + 'in `undefined` being returned. If you need to access the same ' + 'value within the child component, you should pass it as a different ' + 'prop. (https://fb.me/react-special-props)', 'displayName' in type ? type.displayName: 'Element' ); } return undefined; }, configurable: true, }); } if (!props.hasOwnProperty('ref')) { Object.defineProperty(props, 'ref', { get: function() { if (!specialPropRefWarningShown) { specialPropRefWarningShown = true; warning( false, '%s: `ref` is not a prop. Trying to access it will result ' + 'in `undefined` being returned. If you need to access the same ' + 'value within the child component, you should pass it as a different ' + 'prop. (https://fb.me/react-special-props)', 'displayName' in type ? type.displayName: 'Element' ); } return undefined; }, configurable: true, }); } } } </ins> return ReactElement( type, key,

The props and are reserved by React, and used internally. Component authors may attempt to access these properties (thinking they could read the value, as per ). We could use (in dev mode) to warn if or is accessed, and point the user to a note/discussion somewhere. That way, users who actually run into the issue will always get a timely message that sends them directly to the relevant explanation/discussion. This would be a good first bug, if we decide we actually want to do it.
This sounds like a great idea to me!
Yeah this seems reasonable.
hi, I am interested in working on this; as I am looking forward to contribute. Kindly show me the way. Thanks in advance!
Take a look at , that should give you a good start and a good idea of what we would be looking for.
Thanks Checking it out right away.
I have taken a look at the pull request, and associated code review comments. It seems the warn-once policy is required here, as implemented in I am not sure I fully understand how this module achieves this, so I am reading it now. As per the code review comments in , I am using the URLs instead of StackOverflow URLs. But the comments over there also mentioned that the PR might break some test cases. I am not sure about the edge cases here. I feel like I could use some help on understanding this. Instead of using GitHub issue comments, is it possible to use some chat-platform such as IRC or slack room or Gitter?
The module achieves deduplication by setting a boolean if it has already warned. The comments about breaking tests are referring to the failing unit tests. Just run and to verify that everything is working before pushing your changes. There are many places where you can discuss, including the IRC channel and/or reactiflux. There are also github issues (which is what our core team predominantly uses), as well as several other channels. The community is pretty big, but nothing is quite as good as reading through the code and github issues, IMHO.
Sorry, I was away. is ready to be reviewed.


Question: ;(function(){ var urls = [ <ins> '../src/shared/vendor/third_party/webcomponents.js', </ins> '../vendor/jasmine/jasmine.js', '../vendor/jasmine/jasmine-support.js', '../vendor/jasmine/jasmine-html.js',

Our tests currently only pass in the browser when running in Chrome. This is because it supports WebComponents already. However they fail in every other browser. I think this is because of when is actually loaded. It's currently getting packaged into react-test because we're requiring it. It creates a new which is resulting in nodes we create with to have a different prototype than what is expected in WebComponents. WebComponents's new Node prototype has a different implementation of which does an check which our nodes are failing. I think if we loaded into the browser before we loaded JS, the node we create for markup wrapping would have the right prototype.


Question: ); } <ins> function _assertCheckedLink(input) { _assertSingleLink(input); invariant( input.props.checked == null && input.props.onChange == null, 'Cannot provide a checkedLink and a checked property or onChange event. ' + 'If you want to use checked or onChange, you probably don't want to ' + 'use checkedLink' ); } </ins> /** * @param {SyntheticEvent} e change event to handle */

When using ReactLink with checkboxes or dropdowns, the state should not be bound to 'value', but to 'checked' and 'selected' instead.
I guess it's not obvious what the API should be here. I suppose the most obvious way is to do but keep as-is (and should still not work). Any opinions?
Either or change to do the same thing as ?


Question: // The error will correctly point to `url` in Firefox. e.fileName = url; } <del> e.message += url + ':' + e.lineNumber + ':' + e.column; </del> <ins> e.message += url + ':' + e.lineNumber + ':' + e.columnNumber; </ins> } else { e.message += location.href; }

When attempting to use a react class with a lowercase ClassName, the transformer is not able to display line on which the error occurred. It turns out that the event variable passed to the to function does not contain an attribute called lineNumber. An error is thrown that states: Uncaught TypeError: Cannot read property 'replace' of undefined The actual error has only the properties and . Error: Lower case component names (myClass) are no longer supported in JSX: See at
What environment/browser are you in?
I am running Yosemite and in Chrome. Also using the jsxtransformer and react provided by the CDN. On Tuesday, November 25, 2014, Paul O’Shannessy wrote: Cooper Union EE' 14


Question: getDisplayName, getDisplayNameForReactElement, } from 'react-devtools-shared/src/utils'; <ins> import {format} from 'react-devtools-shared/src/backend/utils'; </ins> import { REACT_SUSPENSE_LIST_TYPE as SuspenseList, REACT_STRICT_MODE_TYPE as StrictMode,

This function will throw this error if one of the arguments is type of . The error is swallowed but it does interfere with debugging. When I run with the "pause on caught exceptions" I get trapped here all the time. Can we change into ??? Every time No response 13.2- TypeError: Cannot convert a Symbol value to a string No response No response No response


Question: "version": "4.10.1", "version_name": "4.10.1", <del> "minimum_chrome_version": "49", </del> <ins> "minimum_chrome_version": "60", </ins> "icons": { "16": "icons/16-production.png",

We currently build DevTools to target Chrome 49 and Firefox 54. These are super old browser versions and they did not have full ES6 support, so the generated build is more bloated than it needs to be. DevTools uses most modern language features. Off the top of my head, the following features are used (basically everything but async and generator functions): The above min browser versions come from Assuming I'm not forgetting things, it looks like we'd need to target Chrome 60+ (released 2017-07-25) and Firefox 55+ (released 2017-04-18). This seems like a reasonable set of browsers to target. Interestingly enough, according to , but I think certain details (like spread in object literals) weren't included in the original spec and/or weren't until later. Note that we can't remove the IE 11 target from the backend yet due to Hermes (React Native) ES6 support but that should be doable by the end of the year given current engineering targets. But we could update the frontend target, as well as the targets for the extensions and the package. It would be good to increase the browser versions we target to at least the version numbers mentioned above, rebuild the DevTools, and compare bundle sizes and generated code.


Question: * `jscodeshift -t react/packages/react-codemod/transforms/findDOMNode.js <file>` <ins> `react-to-react-dom` updates code for the split of the `react` and `react-dom` packages (e.g., `React.render` to `ReactDOM.render`). It looks for `require('react')` and replaces the appropriate property accesses using `require('react-dom')`. It does not support ES6 modules or other non-CommonJS systems. We recommend performing the `findDOMNode` conversion first. * `jscodeshift -t react/packages/react-codemod/transforms/react-to-react-dom.js <file>` * After running the automated codemod, you may want to run a regex-based find-and-replace to remove extra whitespace between the added requires, such as `codemod.py -m -d src --extensions js '(var Reacts*=s*require(.react.);)nn(s*var ReactDOM)' '1n2'` using https://github.com/facebook/codemod. </ins> `pure-render-mixin` removes `PureRenderMixin` and inlines `shouldComponentUpdate` so that the ES2015 class transform can pick up the React component and turn it into an ES2015 class. NOTE: This currently only works if you

I tried doing the following to pick up react-dom: However, it said that the only version available was Poking around on Github yielded a repo called that appears to be linked to Bower. I'm guessing this isn't the right library; what's the dependency installation story going to look like with Bower?
Never mind, just found that it shipped in the same package. However, the documentation is misleading on the :
Thanks, we should fix that.


Question: return result; } <ins> const argvType = Array.isArray(argv.type) ? argv.type : [argv.type]; </ins> const requestedBundleTypes = argv.type <del> ? parseRequestedNames([argv.type], 'uppercase') </del> <ins> ? parseRequestedNames(argvType, 'uppercase') </ins> : []; const requestedBundleNames = parseRequestedNames(argv._, 'lowercase'); const forcePrettyOutput = argv.pretty; const isWatchMode = argv.watch;

React version: 18.x.x up to latest the React repository. : either: - the output of the function logs within the script. Relevant code: Relevant function: The function, responsible for determining whether to include a bundle in the build output, contains incorrect logic for filtering when multiple bundle types are specified. Specifically, the following line causes the issue: This code uses with to check if all requested bundle types are missing in the current bundle type. However, when multiple types are specified, it should skip a bundle only if none of the requested types are present. Here's an example of the incorrect behavior observed during debugging: In this case, even though the is and doesn't include , is incorrectly evaluated as , leading to the bundle not being skipped. The function should correctly filter bundles based on multiple requested types. In the example above, the expected behavior is that should be for the bundle type, as it does not include the type. In general, the function should return (skip the bundle) only if none of the requested types are included in the current bundle type.

<!-- 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: 18.x.x up to latest Node version: 16.x.x up to latest the React repository. : either: - Link to code example: Relevant code: (line 72) Relevant function: The current behavior: When running the commands or , a is thrown: . This is evident in the provided screenshot. The error originates from the function in . The problem stems from how the value is handled. In these specific commands, is passed as an array (e.g., ), but the code incorrectly wraps it in another array: The function then attempts to apply the method to each element of , expecting them to be strings. However, due to the erroneous wrapping, it encounters an array instead, leading to the TypeError. The expected behavior: The or commands should run without errors. The value should be handled correctly even when passed as an array, and bundle type filtering should work as expected. Additional information: The or commands work without issues because the value is passed as a string or undefined. The function generates and arrays based on the provided names ( or ). These arrays are used for bundle filtering in the function.


Question: : data.constructor.name, }; <del> if (typeof data[Symbol.iterator]) { // TRICKY // Don't use [...spread] syntax for this purpose. // This project uses @babel/plugin-transform-spread in "loose" mode which only works with Array values. // Other types (e.g. typed arrays, Sets) will not spread correctly. Array.from(data).forEach( (item, i) => (unserializableValue[i] = dehydrate( item, cleaned, unserializable, path.concat([i]), isPathAllowed, isPathAllowedCheck ? 1 : level + 1, )), ); } </del> <ins> // TRICKY // Don't use [...spread] syntax for this purpose. // This project uses @babel/plugin-transform-spread in "loose" mode which only works with Array values. // Other types (e.g. typed arrays, Sets) will not spread correctly. Array.from(data).forEach( (item, i) => (unserializableValue[i] = dehydrate( item, cleaned, unserializable, path.concat([i]), isPathAllowed, isPathAllowedCheck ? 1 : level + 1, )), ); </ins> unserializable.push(path);

This is not important but it seems that this if statement is superfluous since always returns a string.
Yeah, looks like maybe this got broken during a refactor (). Actually since we check the type right above, maybe the condition should have just been deleted entirely. (I don't remember this code very well.)
Hey, I'm gonna pick this up and try to get a PR through to tidy this :) This would be my first issue in this repo. I've given the contribution guidelines a read through, and so will do my best to follow all the CoC and best practices in there.
This issue is all yours I've the "good first issue (taken)" label so that others will know not to start work on the issue. If you change your mind about the issue, no worries! Just let me know so that I can remove the label and free it up for someone else to claim. Cheers!
Hey! Raised a PR for this. Couldn't find any unit tests that covered the function here, and I started to write a few, but thought that it was probably out of scope of this PR. Can definitely create some tests for this function if needed though!


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

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


Question: expect(console.error.argsForCall.length).toBe(0); }); <ins> it('should replace state', function() { var Moo = React.createClass({ getInitialState: function() { return {x: 1}; }, render: function() { return <div />; } }); var moo = ReactTestUtils.renderIntoDocument(<Moo />); moo.replaceState({y: 2}); expect('x' in moo.state).toBe(false); expect(moo.state.y).toBe(2); }); it('should support objects with prototypes as state', function() { var NotActuallyImmutable = function(str) { this.str = str; }; NotActuallyImmutable.prototype.amIImmutable = function() { return true; }; var Moo = React.createClass({ getInitialState: function() { return new NotActuallyImmutable('first'); }, render: function() { return <div />; } }); var moo = ReactTestUtils.renderIntoDocument(<Moo />); expect(moo.state.str).toBe('first'); expect(moo.state.amIImmutable()).toBe(true); var secondState = new NotActuallyImmutable('second'); moo.replaceState(secondState); expect(moo.state.str).toBe('second'); expect(moo.state.amIImmutable()).toBe(true); expect(moo.state).toBe(secondState); moo.setState({str: 'third'}); expect(moo.state.str).toBe('third'); // Here we lose the prototype. expect(moo.state.amIImmutable).toBe(undefined); // When more than one state update is enqueued, we have the same behavior var fifthState = new NotActuallyImmutable('fifth'); ReactUpdates.batchedUpdates(function() { moo.setState({str: 'fourth'}); moo.replaceState(fifthState); }); expect(moo.state).toBe(fifthState); // When more than one state update is enqueued, we have the same behavior var sixthState = new NotActuallyImmutable('sixth'); ReactUpdates.batchedUpdates(function() { moo.replaceState(sixthState); moo.setState({str: 'seventh'}); }); expect(moo.state.str).toBe('seventh'); expect(moo.state.amIImmutable).toBe(undefined); }); </ins> });

I'm still learning React, so it's possible I'm misunderstanding something. I'm trying to use React with , and hit a stumbling block, by upgrading to React 0.13. There is on the repository, that explains how to use immutable as a react state, and it provides the following example (I transpiled it to ES3): This works great in 0.12, but in 0.13, you will receive the following error when clicking on the div: Putting a breakpoint on the error, and inspecting with a debugger reveals that all the methods on have disappeared. Is this the expected behavior in 0.13?
should be a plain object, you're not allowed to put classes in there.
So the wiki page I linked to is incorrect? It would make working with (and probably other immutable implementions) a pita, since you would have to pack/unpack the object every time you store/retrieve it.
Seems so... cc
I encountered the same thing in 0.12, storing an immutable-js object on the state directly clobbers it,but simply putting it under an attribute works fine. E.g. .
I am experiencing this after upgrading to 0.13 as well. It didn't seem to be a problem in react 0.12. It seems to almost make sense that state could be an immutable object since equality comparison is cheap. I could nest my state object under state ( yuck) but it seems like it would create a lot of boilerplate code that I didn't need in 0.12
I think you can +1 in
Yeah this bit me bad... I used an as all my state and not a plain object, which worked absolutely great in 0.12 and broke in 0.13. This forces me to add a bunch of useless vanilla objects with a single child prop to hold my immutable map.
Since I was working with a simple map structure, toObject saved me... e.g. Not sure how well this work with more complex object structures however.
Has there been any movement on this? My project has been on hold since I don't know if I should: a.) stay on React 0.12 where I could use Immutable maps for state. b.) Move all my immutable maps to child of a single-item map. or c.)

leave things as they are and this will be supported in the future.
AFAIK this is not going to change. Personally I still don't understand why people want to put third-party objects as state, I don't see what benefit there is. What's wrong with just using ?
For me there were two main advantages. ) My stores already deal in immutable hashes, With react 0.12 I didn't have to bother converting them ) Deep comparison for updates is simple with immutable objects. With react 0.12 when you setState with an immutable object, if any of it's contents had changed, it would re-render. If it was the same, it would not. Comparing immutable objects is cheap. Deep comparing hashes is not. There is more upfront cost with the immutable objects, but they are way easier to reason about wether or not they have changed. If there is definitely no plan to support this then I suppose the best plan of action is to to_js everything and manually deep compare?
There is movement on which would get rid of replaceState and add better immutable-js support (and perhaps other libraries) in the core. However, it was not our intention to break the old behavior of replaceState in 0.13 so this seems like a bug to me. Do we maybe want to patch release this if there is an easy fix?
1) I can't speak for this, but using a store's data for the singular state object seems rather limiting, you're now unable to include any other stores or introduce any other locally relevant state for the component right? 2) Is straight-forward with objects as well, immutability is not a concept that is unique to immutable-js. Depending on the underlying behaviors you can use just or a simple reusable shallow equality test with plain objects too. But does actually intend to allow replacing the "state object" vs just simply understanding how to iterate over generic maps/sets?
) Yes, I do have some components that use data from multiple stores, and those end up as different elements under a hash. When I have a component that only uses the data from one store, it is sort of silly to have it nested as a single element in a hash. ) "you can use just === or a simple reusable shallow equality test with plain objects too" is my point exactly, usually my objects are just one level deep and this is fine.

I sometimes they are not though and with Immutable-js objects I can use === with deeply nested objects. If I use immutable-js for everything, I don't have to worry about it.
not sure that it will be the cleanest thing. This is a result of your changes . Right now we just have a but we don't know what each thing in the queue is (did it come from a or ). We could wrap each item in the queue so we know what it came from, so instead of we have . That would allow us to stack and calls (which I don't think we actually handle correctly now). But the simplest case where you're only using , we can probably just change this line:
We could take something in 0.13.4 (not 0.13.3, shipping that today). But it needs to bake first. Both changes I mentioned would change behavior so there's some risk. The first is more complete, the latter trades 1 bug for a slightly less bad bug (setState(), replaceState() in the same update queue will result in the object passed to setState being used as the replacement since we only have a single pendingReplace flag)
Actually, this came from . There is a simple fix: Because the queue is emptied for every replaceState, since nothing earlier in the queue could've affected the result:
Ah, truth. is fixing and it's small and let's just take it in 0.13.3 so we don't have to do another patch release so soon after.
So, the issue was fixed in , but what about components using ? I'm seeing this when I use
setState merges. Using a non-plain object with it isn't supported. You can put whatever object you want on an inner state key (, , etc.).


Question: typeof setSuspenseHandler === 'function' && typeof scheduleUpdate === 'function'; <del> // Set of Fibers (IDs) with recently changed number of error/warning messages. const fibersWithChangedErrorOrWarningCounts: Set<number> = new Set(); </del> <ins> // Tracks Fibers with recently changed number of error/warning messages. // These collections store the Fiber rather than the ID, // in order to avoid generating an ID for Fibers that never get mounted // (due to e.g. Suspense or error boundaries). // onErrorOrWarning() adds Fibers and recordPendingErrorsAndWarnings() later clears them. const fibersWithChangedErrorOrWarningCounts: Set<Fiber> = new Set(); const pendingFiberToErrorsMap: Map<Fiber, Map<string, number>> = new Map(); const pendingFiberToWarningsMap: Map<Fiber, Map<string, number>> = new Map(); </ins> // Mapping of fiber IDs to error/warning messages and counts. <del> const fiberToErrorsMap: Map<number, Map<string, number>> = new Map(); const fiberToWarningsMap: Map<number, Map<string, number>> = new Map(); </del> <ins> const fiberIDToErrorsMap: Map<number, Map<string, number>> = new Map(); const fiberIDToWarningsMap: Map<number, Map<string, number>> = new Map(); </ins> function clearErrorsAndWarnings() { // eslint-disable-next-line no-for-of-loops/no-for-of-loops <del> for (const id of fiberToErrorsMap.keys()) { fibersWithChangedErrorOrWarningCounts.add(id); updateMostRecentlyInspectedElementIfNecessary(id); </del> <ins> for (const id of fiberIDToErrorsMap.keys()) { const fiber = idToArbitraryFiberMap.get(id); if (fiber != null) { fibersWithChangedErrorOrWarningCounts.add(fiber); updateMostRecentlyInspectedElementIfNecessary(id); } </ins> } // eslint-disable-next-line no-for-of-loops/no-for-of-loops <del> for (const id of fiberToWarningsMap.keys()) { fibersWithChangedErrorOrWarningCounts.add(id); updateMostRecentlyInspectedElementIfNecessary(id); </del> <ins> for (const id of fiberIDToWarningsMap.keys()) { const fiber = idToArbitraryFiberMap.get(id); if (fiber != null) { fibersWithChangedErrorOrWarningCounts.add(fiber); updateMostRecentlyInspectedElementIfNecessary(id); } </ins> } <del> fiberToErrorsMap.clear(); fiberToWarningsMap.clear(); </del> <ins> fiberIDToErrorsMap.clear(); fiberIDToWarningsMap.clear(); </ins> flushPendingEvents(); } <del> function clearErrorsForFiberID(id: number) { if (fiberToErrorsMap.has(id)) { fiberToErrorsMap.delete(id); fibersWithChangedErrorOrWarningCounts.add(id); flushPendingEvents(); } </del> <ins> function clearMessageCountHelper( fiberID: number, pendingFiberToMessageCountMap: Map<Fiber, Map<string, number>>, fiberIDToMessageCountMap: Map<number, Map<string, number>>, ) { const fiber = idToArbitraryFiberMap.get(fiberID); if (fiber != null) { // Throw out any pending changes. pendingFiberToErrorsMap.delete(fiber); </ins> <del> updateMostRecentlyInspectedElementIfNecessary(id); } </del> <ins> if (fiberIDToMessageCountMap.has(fiberID)) { fiberIDToMessageCountMap.delete(fiberID); // If previous flushed counts have changed, schedule an update too. fibersWithChangedErrorOrWarningCounts.add(fiber); flushPendingEvents(); </ins> <del> function clearWarningsForFiberID(id: number) { if (fiberToWarningsMap.has(id)) { fiberToWarningsMap.delete(id); fibersWithChangedErrorOrWarningCounts.add(id); flushPendingEvents(); </del> <ins> updateMostRecentlyInspectedElementIfNecessary(fiberID); } else { fibersWithChangedErrorOrWarningCounts.delete(fiber); } </ins> } <ins> } </ins> <del> updateMostRecentlyInspectedElementIfNecessary(id); </del> <ins> function clearErrorsForFiberID(fiberID: number) { clearMessageCountHelper( fiberID, pendingFiberToErrorsMap, fiberIDToErrorsMap, ); } function clearWarningsForFiberID(fiberID: number) { clearMessageCountHelper( fiberID, pendingFiberToWarningsMap, fiberIDToWarningsMap, ); </ins> } function updateMostRecentlyInspectedElementIfNecessary(

the block to inspect "Component" in DevTools : "Could not inspect element with id 5" Originally reported in https://user- Every time
Here's another Chrome extension build with the fix from :
Everything fixed. Awesome :+1:
FYI just published as 4.13.4


Question: // See how long the subsequent batch of React work was. const [startTime, stopTime] = getBatchRange(batchUID, profilerData); if (stopTime - startTime > NESTED_UPDATE_DURATION_THRESHOLD) { <del> schedulingEvent.warning = WARNING_STRINGS.NESTED_UPDATE; </del> <ins> // Don't warn about transition updates scheduled during the commit phase. // e.g. useTransition, useDeferredValue // These are allowed to be long-running. if ( !schedulingEvent.lanes.some( lane => profilerData.laneToLabelMap.get(lane) === 'Transition', ) ) { schedulingEvent.warning = WARNING_STRINGS.NESTED_UPDATE; } </ins> } }); state.potentialSuspenseEventsOutsideOfTransition.forEach(

This feature is meant to warn about sync priority updates that block paint (e.g. set state in layout effect) but it appears to also warn for transition priority updates. We should fix this.


Question: chrome.runtime.onMessage.addListener(onPortMessage); chrome.devtools.inspectedWindow.eval(` <del> window.postMessage({ source: 'react-devtools-extension', extensionId: "${CURRENT_EXTENSION_ID}" payload: { type: 'fetch-file-with-cache', url: "${url}", }, }); `); </del> <ins> window.postMessage({ source: 'react-devtools-extension', extensionId: "${CURRENT_EXTENSION_ID}", payload: { type: 'fetch-file-with-cache', url: "${url}", }, }, '*'); `); </ins> }; // Fetching files from the extension won't make use of the network cache

a website that uses React. an element that uses Hooks. to load hook names. hook names always fails: !
Fix landed in , it should be a few days before it can be published to the Chrome Web Store, since it needs to go through the review process.


Question: if (__DEV__) { if (typeof (type: any).tag === 'number') { console.error( <del> 'Received an unexpected object in getComponentName(). ' + </del> <ins> 'Received an unexpected object in getComponentNameFromType(). ' + </ins> 'This is likely a bug in React. Please file an issue.', ); }

A very small thing, would it be better to change the to in the error log since we separated the original logic into two functions (, )? Although it wouldn't be an issue for the authors, it feels like it would be better to sync it with the function name? Would you mind renaming it in the next 'typo fixing'?
Thanks!


Question: // Without this, we would see a "Download failed: network error" failure. let downloadUrl = null; <del> export function downloadFile(filename: string, text: string): void { </del> <ins> export function downloadFile( element: HTMLAnchorElement, filename: string, text: string, ): void { </ins> const blob = new Blob([text], {type: 'text/plain;charset=utf-8'}); if (downloadUrl !== null) {

Hi, long time user, first time issuer. I think I found a bug with the Profiler component. When I click on the button at the top nothing happens and there appears to be no new files in my Downloads folder. I think it might be silently failing and that's why I am not getting any response. Has anyone else ran into this issue? Another thing I would like to mention is that I haven't looked through all of the documentation material about the new Profiler. I only read , so if this issue is addressed elsewhere I apologize and also request the source to that solution. Thank you for your time! Versions: *
It seems that this is happening because of the call in the util function. I'll investigate this further.
I fixed the issue. I'll open a PR later today :)


Question:
docs

support

download

blog

github

I am having an issue with text based inputs in React 0.14.3 and React DOM 0.14.3. When the event is fired for an input, the input will be deselected. Here is what this looks like in the UI: ! Here is an example of my components. There is a top-level component, which describes the fields on the form. This component also holds the state of the form and is the only component that extends . For each field in the form, there is a child component—which each has a and child. The form also has one component, which, when clicked, will fire an function with the state of the form. With the exception of , these components are all stateless functional components. The components are controlled. They get their value from the top level form component. The state is properly updated in this top level after the event is fired—as you would expect things to typically work with a controlled form. This state is then passed down via props to the input. I've been trying to figure out what could possibly be the cause of this weird deselection issue, but haven't made any progress... any ideas? Thanks.
This causes it: On every render the is a different random value. When the key is different, then React will not reuse the old component. So you lose focus because the input got replaced.
Ah, right, that would make sense. Bad mistake! Thanks.
as a key is definitely a bad idea
Haha, yes. I have long sense moved away from this solution.


Question: description: How to build advanced composite components. layout: docs prev: event-handling.html <del> next: api.html </del> <ins> next: mixins.html </ins> --- Composite components extend a `ReactCompositeComponent` base class that provides

There was another issue tracking this , but it looks like it got merged into an issue that was already closed so it never got fixed.
There's also .
SVG images are an important part of my current project - is there anything I could do to help push this issue through?
is a newer PR without the merge conflicts of
Closed with


Question: safeUnmount(); node.innerHTML = nodeWaitingToConnectHTML; <ins> disconnectedCallback(); </ins> } function onError({code, message}) {

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


Question: id: docs-api title: React API layout: docs <del> prev: advanced-components.html </del> <ins> prev: mixins.html </ins> --- ## React

There was another issue tracking this , but it looks like it got merged into an issue that was already closed so it never got fixed.
There's also .
SVG images are an important part of my current project - is there anything I could do to help push this issue through?
is a newer PR without the merge conflicts of
Closed with


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

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


Question: @include clearfix; } <ins> /* JSX Compiler */ .jsxCompiler { margin: 0 auto; padding-top: 20px; width: 1220px; label.compiler-option { display: block; margin-top: 5px; } #jsxCompiler { margin-top: 20px; } .playgroundPreview { padding: 0; width: 600px; pre { @include code-typography; } } .playgroundError { // The compiler view kills padding in order to render the CodeMirror code // more nicely. For the error view, put a padding back padding: 15px 20px; } } </ins> .docs-prev { float: left; }

Did not know where to post this best. Since some weeks, the layout looks broken on Google Chrome 43, Linux Screenshot: !
Not Linux specific; broken in all browsers / operating systems. This is probably a good first bug if someone wants to submit a pull request.
Closed in .


Question: ); break; case ReactMultiChildUpdateTypes.TEXT_CONTENT: <del> update.parentNode[textContentAccessor] = update.textContent; </del> <ins> updateTextContent( update.parentNode, update.textContent ); </ins> break; case ReactMultiChildUpdateTypes.REMOVE_NODE: // Already removed by the for-loop above.

On re-render, we innerText. This causes inconsistencies in rendering whitespace. See demo: We should make sure this doesn't happen.
We switched to use but it broke some contentEditable stuff internal to FB. knows more.
I'm switching it back (D1174395), but regardless, this is an innerText issue. Browsers that don't have textcontent (ie8) suffer
looks like this was brought up in
Right, we should also do the right thing in IE8.
jQuery empties then adds a text node. Relevant commits: ()
okay interesting. I'll do this for ie8
I have a patch almost ready.
I'm curious if is a simpler solution to the newline problem (for IE8), or if that only works for innerHTML.
hmm interesting. We definitely want to preserve whitespace though. (because of and and )


Question: .example-enter.example-enter-active, .example-leave { margin-left: 0; <del> opacity: 0.99; </del> <ins> opacity: 1; </ins> } .animateExample {

Hello, Today I have spotted the bug(?) in IE10/IE11: while setting the inner HTML on any element (, , ) using property the browser will raise an error . I use this with SSR, but the actual HTML received from the server is good, so probably there's a problem with func. Some code: where is some string that contains HTML. !
Hey! This was fixed in and is a known issue. A fix should be out in the next release. However thank you for the great write up!
React has been released. Please update , , and (if you use it) to this version and let us know if it solved the issue! We’d appreciate if you could test before Monday when we plan to get out.
Hi Dan, everything is working now, thank you!


Question:
'Invariant Violation: React.render(): Invalid component element.' ); });  it('does not break when updating during mount', function() { var Child = React.createClass({ componentDidMount() { this.props.onMount && this.props.onMount(); }, render() { if (!this.props.visible) { return null; } return
hello world
; } }); var Parent = React.createClass({ update() { this.forceUpdate(); }, render() { return (
 <Child key="1" visible={false} /> <Child key="0" visible={true} onMount={this.update} /> <Child key="2" visible={false} />
 ); } }); expect(function() { ReactTestUtils.renderIntoDocument(<Parent/>) }).not.toThrow(); });  });

tl;dr: If you have a component that returns and it rerenders, the noscript tag is unmounted and a new one is created because shouldUpdateReactComponent gets and and returns false. This came out of some internal components that were breaking after the most recent update. I haven't gone to see if this is more widely broken - it might have been before any of the recent updates, just that the empty component is triggering it reliably. I've been some reports of having similar weird problems that we couldn't track down. It's use of is very similar to what's happening in . The trigger here is that we're triggering an update during the mount phase. When we do this works correctly because it's before which is triggering to rerender. is the broken one because its hasn't been called yet. So we actually call its first. Then we still call its . There's also the whole question of why we're trying to unmount anything at all here. It seems like we shouldn't be doing that. cc Drop this into examples/basic-jsx-harmony and debug with pausing on caught exceptions. I some breakpoints in ReactEmptyComponent to make it super obvious.
Why it's unmounting: When comparing the old to the new in , is actually whereas is , so returns false.
Why it's throwing: the three componentDidMount calls get queued in the order they were rendered (Child 0's null, Child 1, Child 2's null), but because batching doesn't happen on an initial render (something I've been meaning to make happen…), the forceUpdate happens synchronously and causes the unmount/remount of both child components, after which the old enqueued Child 2 null did-mount callback runs and throws, because that component isn't mounted any more.
(Two issues; we should fix both.)
The first one is a new regression, right?
Not sure, but I think so. I a test recently to ensure that text components don't get remounted on update; we should add one for empty components too.
Initial render isn't asynchronous but to change it, I think we'd need to change the API to pass the instance to a callback instead of synchronously returning it. We should be able to queue up new updates during initial render though. So that they're guaranteed to happen after the queue as processed.

Right -- that's what we do already for new mounts of child components within a larger update.
The second issue should be fixed now because we batch on initial render. Not sure about the first; it's probably still a problem.
I just ran into this (I think) and made a JSFiddle for it
Maybe you can fix this.
Suggestion to use instead of so that it doesn't mess up s and s.


Question: <ins> /** * Copyright (c) 2013-present, Facebook, Inc. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. * * @providesModule Circle.art * @typechecks * * Example usage: * <Circle *   radius={10} *   stroke="green" *   strokeWidth={3} *   fill="blue" * /> * */ 'use strict'; var assign = require('object-assign'); var PropTypes = require('prop-types'); var React = require('react'); var ReactART = require('react-art'); var createReactClass = require('create-react-class'); var Path = ReactART.Path; var Shape = ReactART.Shape; /** * Circle is a React component for drawing circles. Like other ReactART * components, it must be used in a <Surface>. */ var Circle = createReactClass({ displayName: 'Circle', propTypes: { radius: PropTypes.number.isRequired, }, render: function render() { var radius = this.props.radius; var path = Path() .moveTo(0, -radius) .arc(0, radius * 2, radius) .arc(0, radius * -2, radius) .close(); return React.createElement(Shape, assign({}, this.props, {d: path})); }, }); module.exports = Circle; </ins>

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


Question: 'es6-rest-params': es6RestParameters.visitorList, 'es6-templates': es6Templates.visitorList, 'es7-spread-property': es7SpreadProperty.visitorList, <del> 'react': react.visitorList.concat(reactDisplayName.visitorList) </del> <ins> 'react': react.visitorList.concat(reactDisplayName.visitorList), 'reserved-words': reservedWords.visitorList </ins> }; var transformSets = {

When I run: The following error is thrown: I'm trying to use a library called in an isomorphic app, which needs server-side rendering. The module works fine client-side, but the JSX/ES6 isn't playing nice on the server even though the server's already set up to render React components and other JSX code. As stated , it seems there's a transformation supported in (via its flag) which isn't supported in . I say "seems" because I have a hard time believing can't do the same thing. What am I missing?


Question: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.3.538.tgz#15226638ee9db5d8e74f4c860cef6078d8e1e871" integrity sha512-rlyYXLlOoZkJuvY4AJXUpP7CHRVtwZz311HPVoEO1UHo/kqDCsP1pNas0A9paZuPEiYGdLwrjllF2hs69NEaTw== <del> electron@^9.1.0: version "9.1.0" resolved "https://registry.yarnpkg.com/electron/-/electron-9.1.0.tgz#ca77600c9e4cd591298c340e013384114d3d8d05" integrity sha512-VRAF8KX1m0py9I9sf0kw1kWfeC87mlscfFcbcRdLBsNJ44/GrJhi3+E8rKbpHUeZNQxsPaVA5Zu5Lxb6dV/scQ== </del> <ins> electron@^11.1.0: version "11.1.1" resolved "https://registry.yarnpkg.com/electron/-/electron-11.1.1.tgz#188f036f8282798398dca9513e9bb3b10213e3aa" integrity sha512-tlbex3xosJgfileN6BAQRotevPRXB/wQIq48QeQ08tUJJrXwE72c8smsM/hbHx5eDgnbfJ2G3a60PmRjHU2NhA== </ins> dependencies: "@electron/get" "^1.0.1" "@types/node" "^12.0.12"

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

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


Question: <del> --- pygments: true </del> <ins> --- markdown: redcarpet </ins> name: React <ins> redcarpet: extensions: - fenced_code_blocks </ins> react_version: 0.3.0 <del> exclude: </del> <ins> pygments: true exclude: </ins> - Gemfile - Gemfile.lock - README.md - Rakefile <del> redcarpet: extensions: - fenced_code_blocks markdown: redcarpet </del> baseurl: /react

There was another issue tracking this , but it looks like it got merged into an issue that was already closed so it never got fixed.
There's also .
SVG images are an important part of my current project - is there anything I could do to help push this issue through?
is a newer PR without the merge conflicts of
Closed with


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

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


Question: 'a valid ReactComponent.' ); }); <ins> it('allows setState in componentWillMount without using DOM', function() { var Component = React.createClass({ componentWillMount: function() { this.setState({text: 'hello, world'}); }, render: function() { return <div>{this.state.text}</div>; } }); ReactReconcileTransaction.prototype.perform = function() { // We shouldn't ever be calling this on the server throw new Error('Browser reconcile transaction should not be used'); }; var markup = ReactServerRendering.renderComponentToString( <Component /> ); expect(markup.indexOf('hello, world') >= 0).toBe(true); }); </ins> }); });

After upgrading from React 0.10 to 0.11 our handler fires during server-side rendering and ends up in which requires access to the DOM, i.e. : Redacted stack trace:
I have the same problem
I'm having the same problem. I was so happy to see you finally the hrefLang attribute support and tried to upgrade immediately. Unfortunately this problem is keeping me from upgrading.
FYI, we worked around it by using which might work in your case too depending on your use case.
Wow this sounds like a big regression. Can you construct a simple repro case?
I will try but I probably won’t be able to until Sunday the earliest. Frankly, the error doesn’t happen with for every handler we have, so there might be something we’re doing wrong.
This might happen always if you setState within a componentWillMount? Agree that we need to fix this.
For me it happens when I do setState in componentWillMount. Will try to come up with the simplest repro case.
Oh, setState() is probably going through ReactUpdates which is using the (browser-specific as of 0.11) ReactReconcileTransaction I think.
Yes, we are using in the failing handler. Is that a bad practice?
maybe? why are you doing that vs ?
Here’s the part of the stack trace ( is the offending handler):
This is the most simple example that reproduces the problem:
Trying to figure out if the right move is to fix in or instead forbid in in favor of . Thoughts
The former; we've always said this is supported.
but why do we support it? seems like "more than one way to do it"...
One use case is computing something based on props in both componentWillMount and componentWillReceiveProps; you can make a helper and call it in both places.
does the same thing, no?
Based on your example, I can see now that calling is not very elegant in but disallowing it but would be a breaking change based on the current documentation: I’m ok with a breaking change in releases as long as it’s documented à la change.
We're going to put out 0.11.1 with this (and a couple other ride-alongs). Thanks for bringing it to our attention!
:+1: Thanks :smile:
Hi guys! The issue referenced above looks (reactjs/react-rails) related to this one... input welcome!


Question: } }); <del> // This simulates the scenario in https://github.com/facebook/react/issues/17626. </del> <ins> function initFauxDevToolsHook() { const onCommitFiberRoot = jest.fn(); const onCommitFiberUnmount = jest.fn(); let idCounter = 0; const renderers = new Map(); // This is a minimal shim for the global hook installed by DevTools. // The real one is in packages/react-devtools-shared/src/hook.js. global.__REACT_DEVTOOLS_GLOBAL_HOOK__ = { renderers, supportsFiber: true, inject(renderer) { const id = ++idCounter; renderers.set(id, renderer); return id; }, onCommitFiberRoot, onCommitFiberUnmount, }; } // This simulates the scenario in https://github.com/facebook/react/issues/17626 </ins> it('can inject the runtime after the renderer executes', () => { if (__DEV__) { <del> // This is a minimal shim for the global hook installed by DevTools. // The real one is in packages/react-devtools-shared/src/hook.js. let idCounter = 0; const renderers = new Map(); global.__REACT_DEVTOOLS_GLOBAL_HOOK__ = { renderers, supportsFiber: true, inject(renderer) { const id = ++idCounter; renderers.set(id, renderer); return id; }, onCommitFiberRoot() {}, onCommitFiberUnmount() {}, }; </del> <ins> initFauxDevToolsHook(); </ins> // Load these first, as if they're coming from a CDN. jest.resetModules();

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

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

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

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

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


Question: invariant( one[key] === undefined, 'mergeObjectsWithNoDuplicateKeys(): ' + <del> 'Tried to merge two objects with the same key: %s', </del> <ins> 'Tried to merge two objects with the same key: `%s`. This conflict ' + 'may be due to a mixin; in particular, this may be caused by two ' + 'getInitialState() or getDefaultProps() methods returning objects ' + 'with clashing keys.', </ins> key ); one[key] = value;

Understandably general given that this is used to merge a couple things, but the actual use case is when or (or but shh) is used in a mixin and the component and both return an object with the same key. We should make this error mention something about those methods so people have an idea of where to look instead of them coming to IRC and being (rightfully) confused.