Fix 'Should not already be working' error after debugger pause in Firefox#36256
Fix 'Should not already be working' error after debugger pause in Firefox#36256SAY-5 wants to merge 1 commit intofacebook:mainfrom
Conversation
When you hit a breakpoint or call alert() in Firefox mid-render, the browser pauses JS and then fires scheduler callbacks while React's executionContext still has RenderContext/CommitContext set. This made performWorkOnRoot throw "Should not already be working" even though nothing was actually running concurrently. Instead of throwing, reset executionContext to NoContext and log a DEV warning. JS is single-threaded — if we're entering these functions while the context says mid-work, the previous work was frozen by the browser, not running concurrently. Fixes facebook#17355
|
Hi @SAY-5! Thank you for your pull request and welcome to our community. Action RequiredIn 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. ProcessIn 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 If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
2 participants
This fixes the long-standing issue where React throws "Should not already be working" in Firefox (and sometimes Chrome) when you hit a breakpoint or call alert() during a render.
When a debugger breakpoint or alert() pauses JavaScript mid-render, the browser's event loop can still fire scheduled callbacks. React's scheduler picks up one of those callbacks and tries to start new work, but executionContext still has RenderContext or CommitContext set from the paused render. The guard sees this and throws, even though there's no actual concurrent work — JS is single-threaded, the old work is just frozen.
The fix changes both guard locations (performWorkOnRoot and completeRoot) to reset executionContext instead of throwing. In DEV mode we log a console.error so it's still visible if this ever fires outside of a debugging session, which would point to a real bug worth investigating.
Fixes #17355