In bug 960776, react-dev will be used when DevToolsUtils.testing, or DEBUG_JS_MODULES is on, and we can set DTU.testing directly without having to wait for bug 1217503. The reason this is a separate patch is because we have some PropType assertion warnings when using react-dev right now.

Comment on attachment 8680066 [details] [diff] [review] 1217946-react-validation.patch Review of attachment 8680066 [details] [diff] [review]: ----------------------------------------------------------------- FYI, the biggest bottleneck in the tree view's rendering after I added the DFS caching was emitting warnings. So good that we are fixing this, also might want to consider a way to use non-dev react again. r=me with the comments below addressed ::: devtools/client/memory/components/list.js @@ +21,5 @@ > render() { > let { items, onClick, itemComponent: Item } = this.props; > > return ( > + dom.ul({ className: "list" }, ...items.map((item, index) => { This one is just working around the warning, not fixing it. We have a changing number of items and can be added or removed between renders and it wants a key to help figure out which elements can be re-used. The sub-items should provide a key here. ::: devtools/client/memory/components/toolbar.js @@ +40,3 @@ > className: `select-breakdown`, > onChange: e => onBreakdownChange(e.target.value), > + }, ...breakdowns.map(({ name, displayName }) => dom.option({ value: name }, displayName))), Again, these should have keys, not ...'d and inlined to trick react. We even have a `name` that we can use as the key.

Backed out for various devtools test bustages: https://hg.mozilla.org/integration/fx-team/rev/0bf0e3c8f51e

Thanks Wes, fixed the issue from a bad rebase -- Nick's working on fixing our tests to prevent this from happening again to release this for next uplift