Change:
"local-storage-fallback": "^4.1.1", "lodash.throttle": "^4.1.1", "memoize-one": "^3.1.1", <del> "react-virtualized-auto-sizer": "^1.0.2", </del> <ins> "react-virtualized-auto-sizer": "^1.0.6", </ins> "semver": "^6.3.0" } }

Discussion:
devtools "Components" tab At first the component tree won't appear. Once I'm at the "Components" tab, I then have to also refresh the page to make the tree render. And when it does render, it still doesn't work properly. As a note, this issue started happening after I had to forcibly restart my computer. Since then I have tried reinstalling the extension, restarting Chrome, restarting my pc, all of which haven't worked. I'd like to avoid reinstalling Chrome completely but that's the only thing I haven't yet tried. Using Windows 10, btw. Here is what the broken component tree looks like. It's very narrow and the components cannot be selected: ! Every time No response No response No response No response No response No response
Same issue, Chrome v 92.0.4515.107
Same here: ! The Profiler tab seems unaffected Workarounds that don't help: Reloading the page Docking the devtools on the side/bottom Undocking the devtools (a.k.a. open in a window) Resizing the window Fiddling with the setting Resizing the right pane of the component tab
Looks like a CSS issue. I managed to work around it by fiddling with the styles as shown in this video: https://user- Besides the css tweaks to make the tree not so squished, the mouse selection issue has to be worked around separately The nodes are initially selectable with the mouse, but mouse selection breaks permanently if you attempt to use the element picker (I'm guessing it adds and doesn't remove it?) Using other methods of selecting nodes (i.e. searching, keyboard, using the / buttons, etc) still work For anyone curious on how to do what I did in the video: the devtools in undocked mode this will open an "inspector inspector" the properties as shown in the video
Doesn't seem to occur on mac os for me on extension (both from chrome extension store and running from main branch). Could this be os specific?

Version 14.0 (7/16/2021) <img width="1674" alt="Screenshot 2021-07-30 at 00 05 56" src="https://user-"
reproduces for me on: MacOS X 10.14 Chrome Version 92.0.4515.107 (Official Build) (x86_64) (latest) DevTools 4.14.0 (7/16/2021)
Mine is: Windows 10 21H1 (OS Build .1110) Chrome Version 92.0.4515.107 (Official Build) (64-bit) DevTools version 4.14.0- If any developer is unable to reproduce, let me know and I can get you whatever you need (a snapshot of the dom, the css ruleset, a memory dump, of specific nodes, heck even a css fiddle if that's what you need, anything that might help you) Also I know you guys know this but just in case: what I did in the video is by no means a suggestion of what should be done in order to fix the problem. Randomly changing CSS around without understanding what it does is a good way to introduce more bugs
reproduces for me on: Windows 10 Pro (10.0. Build ) Edge Version 92.0.902.62 (Official Build) (64-bit) (latest) DevTools 4.14.0 (7/16/2021)
I also have this problem: MacOS 11.4 Chrome version: Version 92.0.4515.131 (Official Build) (x86_64) DevTools version: 4.14.0 (7/16/2021) Sometimes component tree doesn't show at all, have to reload a page. Even after reloading tree is too narrow and clicks are not coming through. Tried every sane approach to fix (reinstall, reload etc) — nothing helps.
Occurs for me as well: Ubuntu 20.04.2 LTS Chrome: 92.0.4515.107 - also occurs on: 92.0.4515.131 DevTools: 4.14.0 While Chrome is affected for me - FireFox continues to work.

Another report in
I suspect the bug may be caused by this component (which we use in DevTools to auto-expand the Components tree to fill the width and height of the viewport):
Me too. OSX Chrome (the latest) ReactDevTools: Interestingly, the issue is not present in (Brave ).
Tanks As another data point: OS X 11.4 (20F71) Chrome 92.0.4515.131 DevTools (built from HEAD of ) FWIW I've never seen or been able to reproduce this bug myself (and I use DevTools daily). Maybe others can share their configurations and we can spot a pattern.
@ bvaughn So you can't reproduce? What would be helpful for you to track this down?
I have the same issues and also using chrome with latest version and dev tools version on windows 10. Weird thing, is my co-worker with the same versions, it works fine on his end on the same app/site. So no idea what is causing it to not work on my computer.
Could be helpful if you and your coworker could try to further narrow down what the difference is between the two of your setups.
I checked with him quickly and we have pretty much the same extensions. I also did a test in Edge and in Edge it works fine, it only seems to affect my chrome. I also tried to disable all extensions and even did a complete reset of the chrome settings to default values and cleared all cache. The problem still persists. I even thought of disabling hardware acceleration and checked if my settings differed from edge, but no go.
I have a suspicion at whats going on here. I know react-virtualized ~shims ~ has resize detection using scroll event handlers, when it does this, it schedules a to be notified after the layout updates. In this case, if I debug this script, I can see that scheduling any raf in of the devtool will never fire. I suspect a finch trial is being used by the Chromium team to attempt to throttle rAFs in hidden s. This experiment looks the most suspicious, these will show as "Default" for everyone unfortunately. !
Awesome work, this pretty much confirms it. Changing that flag from to solves the issue on my end. Changing it to makes it happen again
Couldn't find the throttle setting mentioned by and where to change it.

But I uninstalled chrome completely and reinstalled it (fresh copy, wiping out all settings) and it fixed it for me.
Could be worth opening a Chromium ticket, but from similar experience this is likely by design. Maybe they could exclude devtools extensions here? I think the fact that this is deep in the ~ polyfill~ resize detection might make it painful to fix in the short term. Maybe it's best to create a branch off of thats used for the plugin that from the scheduler array Alternatively it feels like that ~polyfill~ detection deserves a naive check around and preferring over when hidden.
Fantastic find, Seems like could detect this case (no rAF firing by a certain time) and maybe fallback to using a timer or other debounce technique.
I saw you just picked this up if you have issues in development I have seen Chromium make timers minute aligned when doing background throttling. It's possible it may do the same in this case. If that's the case I know setImmediate polyfills have a trick with a self that could be used.
Thanks for the pointer, Happen to have a code pointer?
Sure! Here's the strategy I was thinking of and here is a reference to the timer alignment I've seen mentioned (not 100% sure it will apply here)
Super helpful. Thanks!
I'm overlooking some important detail here. Enabling/disabling the "Throttle non-visible cross-origin iframes" flag does indeed trigger/fix the bug, but even when this is disabled– animation frames still get called based on my testing, unlike what reported above: (So my idea to detect this case and fallback to a timeout doesn't work.) That being said, just replacing with (and not trying to detect support) fixes the broken behavior.
ah interesting. Just to validate are you registering those callbacks from the context of or . I believe they will only fail to fire from (which is the hidden iframe)
I logging to the feature detection code I wrote (which runs in the same context as the script).
Fixed it by adding a fallback timeout when rAF is used Doesn't feel great but...
Thanks a ton for the info and
This fix has landed. We'll probably release it next week because we're also waiting on another bugfix to unblock the Firefox release.
Related CR bug: