[DevTools] Fix high CPU usage on pages without React (#35515)

[CarlosEduJs]

Summary

• Fixes high CPU usage in React DevTools when browsing pages without React (e.g., Google Search results).

• Motivation: The content script was polling indefinitely with setInterval, sending "hello" messages every 500ms to detect React. On pages without React, this loop never stopped, causing high CPU usage and battery drain.

• Solution: Added a maximum retry limit of 10 attempts (~5 seconds). After this timeout, the polling stops automatically on pages without React, while still allowing enough time for slow-loading React apps to initialize.

How did you test this change?

Manual Testing

Built and tested the extension on both Chrome and Firefox:

• Chrome:

  • Built extension: yarn build:chrome:local
  • Loaded unpacked extension in chrome://extensions/
  • Tested on Google Search (non-React page)
  • Monitored messages in DevTools Console

• Firefox:

  • Built extension: yarn build:firefox:local
  • Loaded temporary add-on in about:debugging
  • Tested on Google Search (non-React page)
  • Monitored messages in DevTools Console

Results

Before fix:

• 100+ "hello" messages sent continuously
• High CPU usage reported by users

After fix:

• Stops after 7-10 messages (~5 seconds)
• No more infinite polling
• React pages (react.dev) still work correctly
• Code Quality Checks
• yarn prettier - Passed
• yarn linc - Passed (lint for changed files)
• yarn flow dom-node - Passed

Screenshot:

Checklist

• Fork the repository and create branch from main
• Run yarn in the repository root
• Code formatted with prettier (yarn prettier)
• Code lints (yarn linc)
• Flow type checks pass (yarn flow dom-node)
• Tested manually on Chrome and Firefox

Related Issue

• Fixes [DevTools Bug]: High CPU usage when viewing Google Search results #35515

[meta-cla]

Hi @CarlosEduJs!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[CarlosEduJs]

The retry limiter definitely helps, it makes the extension way less eager to scream “hello???” forever and burn CPUs. So the PR has real value as a safety valve for people browsing heavy sites (Google, dashboards, etc.).

But the core issue is architectural: DevTools does active polling over a wide-open postMessage channel with no strict origin/protocol validation. On complex pages that relay messages (iframes, sandboxed scripts, whatever), you can end up with feedback loops that keep waking the handshake logic even after retries stop. So limiting retries = good bandaid, but long-term fix needs a more robust handshake mechanism.

I'm also looking into more robust long-term approaches.

[CarlosEduJs]

Update: I've refactored the fix to address the root cause instead of just limiting retries.

• Based on further testing and analysis, I realized that polling via setInterval is inherently resource-intensive and prone to race conditions.

• Changes in the latest commit: I replaced the polling mechanism with an Event-Driven Architecture:

Passive Signaling:

• backendManager.js (Main World) now dispatches a react-devtools-ready event and sets a data-react-devtools-ready attribute on the document when initialized.
• Reactive Listener: proxy.js (Content Script) listens for this event (or checks the attribute) to trigger the handshake.
  Results:

Non-React Pages: Zero code execution loop, resulting in 0% CPU overhead and no console noise.
React Pages: Instant and deterministic connection.
This approach is much more robust and completely eliminates the original issue.