react: [DevTools Bug]: Component tree panel becomes unresponsive after clicking on a few components
Website or app
Multiple; but you can check at https://react-bootstrap.github.io/
Repro steps
- Access a website in Chrome that uses React.
- Open Chrome Developer Tools
- Open the React Developer Tools Components tab/panel
- Click on 5 - 10 components in the component tree individually to inspect them
Notes:
- This started happening on all React-based websites after updating to Chrome Version 102.0.5005.61 on my work MacBook (x86_64) and my personal MacBook (arm64). Reverting back to Chrome 100 seems to help.
- I had a co-worker test as well, with the same result.
- You can still select individual components using the picker, even after the panel locks up.
- The lock-up seems to happen quicker when
Expand component tree by defaultis selected in theComponentstab in the panel settings, but will still lock up if you manually expand enough components.
How often does this bug happen?
Every time
DevTools package (automated)
react-devtools-extensions
DevTools version (automated)
4.24.6 (5/12/2022)
Error message (automated)
None
Error call stack (automated)
N/A
Error component stack (automated)
N/A
GitHub query string (automated)
N/A
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 9
- Comments: 21 (14 by maintainers)
Commits related to this issue
- remove pointerEvents as a temporary fix for #24626 — committed to mondaychen/react by mondaychen 2 years ago
- mock requestAnimationFrame as a temp workaround for #24626 — committed to mondaychen/react by mondaychen 2 years ago
- [DevTools] mock requestAnimationFrame with setTimeout as a temporary fix for #24626 (#24633) * mock requestAnimationFrame as a temp workaround for #24626 * give name to constant variable — committed to facebook/react by mondaychen 2 years ago
- # React DevTools changelog <!-- RELEASE_SCRIPT_TOKEN --> --- ### 4.26.1 October 13, 2022 * [standalone] Stop highlighting events when a component is selected ([tyao1](https://github.com/tyao1) in ... — committed to Belle59/react by Belle59 2 years ago
- [DevTools] permanently polyfill for rAF in devtools_page (#26193) ## Summary We had this as a temporary fix for #24626. Now that Chrome team decides to turn the flag on again (with good reasons e... — committed to facebook/react by mondaychen a year ago
- [DevTools] permanently polyfill for rAF in devtools_page (#26193) ## Summary We had this as a temporary fix for #24626. Now that Chrome team decides to turn the flag on again (with good reasons expl... — committed to facebook/react by mondaychen a year ago
A temporary workaround before we land a fix:
Throttle non-visible cross-origin iframesI found that the unresponsiveness happens after scrolling, and that inspecting the flamegraph container itself and removing
pointer-events: nonefrom the<svg>makes it responsive again. I don’t have the bandwidth to do the fix, but from the source I see in the extension, this might get thrown on the container while scrolling, so something is maybe making it think we’re still scrolling? Hopefully someone can take this and run with it!Editing to add that I also tried the version from March 30th via a CRX and it had the same issue in Chrome 102, so not a recent change. As @mondaychen points out, perhaps an interaction with new Chrome?
Version 4.24.7 with the temporary fix is on Chrome Web Store now. I’m closing this issue. Also for the record Chrome team has decided to revert that change caused this issue.
requestAnimationFrameshould work again on the stable version of Chrome v104+.Yeah. That’s what I was thinking.
I’ve created a repro of the Chrome bug https://github.com/mondaychen/devtools-bug-repro and reported the bug https://bugs.chromium.org/p/chromium/issues/detail?id=1330118
Facing the same problem. (Version 102.0.5005.61 (Official Build) (64-bit).
Same problem here.
Chrome version 102.0.5005.62 on Windows 10