\
:::tip The screenshots shown are from the simulated problem section of the article, not the original code issue, due to privacy concerns.
:::
This bug appeared in a React + TypeScript + Redux + RxJS project.
\ The form had a single numeric fieldquantity. When updated, it triggered a Redux selector (built using reselect) to recalculate the Total cost state synced text.
\ Everything looked fine on the Buyside.
\ But switching to the Sell side caused something bizarre: the page froze instantly when entering even 1.
When typing in the quantity field:
The UI froze completely
The browser tab became unresponsive
The CPU usage 100% in Chrome Performance Monitor. (Sometimes, the JS heap size also keeps increasing)
This wasn’t a typical “slow” render. It was a complete hang.
\ Chrome eventually showed the “Page Unresponsive” dialog & I had to kill the tab.
Common debugging methods didn’t help:
| Attempt | Result | |----|----| | console.log | Never printed anything | | debugger; | Too slow or never triggered | | React DevTools Profiler | Froze with the app | | Chrome Performance Profiler | Couldn’t finish recording | | Removing components | Still froze, even with just the input |
The issue had to be a loop or recursive render running endlessly. But where? :thinking:
Then I came to a realization: if the JavaScript heap keeps growing, JavaScript is still running.
So I opened Chrome DevTools → Sources tab and used the hidden gem: \n Pause Script Execution (⏸️)
:::info Unfortunately, I could not see an explanation of this feature even in the official Chrome DevTools docs: https://developer.chrome.com/docs/devtools/javascript/breakpoint
:::
Steps:
Open Chrome DevTools first! You won’t be able to open them during the freeze.
Reproduce the freeze (enter quantity).
When the tab hangs, open DevTools → Sources tab.
Click the ⏸️ Pause icon (top-right).
Chrome freezes JS execution at that exact line.
Scroll down on the right panel & check the Call Stack panel to trace which functions are currently executing.
Scroll through the parent calls to reveal how the function chain started. You can even click on the parent calls to see their invoked line!
The paused stack revealed a chain of 8+ functions, starting from the onChange handler and ending inside a utility function used by a Redux Reselect selector.
\ Here’s the culprit:
let a = 0; const size = props.size; // expected number, got string while (a < size) { // do something }
Turns out props.size came indirectly from the input value: a string like "5".
\ Due to JS coercion quirks, the loop comparison failed to exit under certain conditions, causing an infinite loop and freezing the entire thread.
\ Fixing it was as simple as converting the value to a number before use:
const size = Number(props.size);
Instantly, the page freeze disappeared :tada:.
You can recreate this exact bug and try the debugging trick yourself by going to this codesandbox link OR running the below code in a new Create React App, but save your work first because this will hang your browser tab 😅
import { useState } from "react"; export default function App() { const [quantity, setQuantity] = useState(""); const handleChange = (e) => { const value = e.target.value; setQuantity(value); const end = Date.now() + 145000; let a = 0; // ❌ Intentional infinite loop while (Date.now() < end) { // Busy-wait a++; } console.log("Done!"); // never reached }; return ( <div style={{ padding: 20 }}> <h2>🧊 Simulate a Page Freeze</h2> <input type="text" placeholder="Enter quantity" value={quantity} onChange={handleChange} /> <p>Type any number and watch Chrome suffer.</p> </div> ); }
Open this code in the above codesandbox or locally.
Type any number in the input.
Watch the tab freeze solid.
Open Chrome DevTools → Sources tab → ⏸️ Pause script execution.
Observe the infinite loop inside handleChange in the call stack.
while loops are sharp tools: one wrong condition and your app becomes a CPU toaster :zippermouthface:.This same technique could help track slow memory leaks→ cases where the JS heap increases gradually.
\ Pausing script execution during idle time might reveal which background processes or subscriptions are still running unnecessarily.
\ But that’s an experiment for another article :wink:.


