ScratchAddons
New Addon: Runtime Safety Guard to Prevent Freezes and Data Loss in Scratch Projects
Why this would be helpful
During Scratch project development, users may unintentionally write high-risk logic—such as infinite cloning, excessive broadcasting, deep recursion, or loops inside custom blocks—that can cause the project to freeze during runtime. This may crash the browser, make the editor unresponsive, or even result in data loss. For beginners, a small mistake can trigger serious consequences. Existing tools like TurboWarp’s loop timing monitor don’t always prevent these issues in complex scenarios. A general-purpose runtime safety mechanism would help users detect and respond to such problems, improving project stability and development experience.
How this addon works
I suggest adding a “Runtime Safety Guard” addon that monitors project behavior dynamically during execution, rather than relying solely on static analysis before running. This addon could:
- Monitor clone creation rate and warn or pause if it spikes abnormally
- Track broadcast frequency, recursion depth, and loop density to detect potential resource exhaustion
- Offer a “Safe Mode” option that limits risky operations when triggered
- Allow users to set custom thresholds (e.g. max clones, max broadcasts, max recursion depth)
- Provide real-time feedback during execution to help users locate the problem
It doesn’t need to catch every issue precisely—just basic protection and alerts during runtime would already help prevent project crashes.
Possible alternatives
- Native runtime resource monitoring in Scratch
- A “Safe Run” button to execute projects in a controlled environment
- Automatic snapshots during execution to recover from freezes
- A “Developer Protection Mode” that limits high-frequency or deep operations
Additional context
I once encountered a freeze while following a griffpatch tutorial. I made a small mistake in a custom block, and the project crashed during execution. I was using TurboWarp with warp timer enabled, but it didn’t help in that case—the project became unresponsive and I lost my progress. I don’t remember the exact code, but here’s another example that reliably reproduces a similar issue:
when I start as a clone
create clone of (myself v)
delete this clone
when [timer v] > (0)
create clone of (myself v)
This code causes an infinite clone loop as soon as the project runs, freezing the browser and making the Scratch editor unusable. While this is an extreme case, similar problems can occur in more complex projects—for example, through recursion or loops inside custom blocks. I hope ScratchAddons considers adding a runtime safety mechanism to help users develop and test projects more safely.
Allow users to set custom thresholds (e.g. max clones, max broadcasts, max recursion depth)
I think simple fixes will do the job:
- For recursive clone creation, limit the number of clones that could be created in between screen refreshes.
- For recursive broadcasts and custom block calls, limit the chain length.
If a limit is exceeded or nearly reached, it could log warning or error messages in the Debugger addon or maybe even trigger a breakpoint pause, allowing you to take action.
Chrome DevTools also has a safeguard: it will sometimes trigger a breakpoint pause before a potential out-of-memory crash.
Also, if Scratch's VM ran on a web worker, then theoretically, it wouldn't block the main thread if project code gets hung.
For recursive broadcasts and custom block calls, limit the chain length.
doesn't this already kinda happen? (the warp timer for custom block calls, which also exists in vanilla Scratch, and for recursive broadcasts there's a whole frame wait)
For recursive broadcasts and custom block calls, limit the chain length.
doesn't this already kinda happen? (the warp timer for custom block calls, which also exists in vanilla Scratch, and for recursive broadcasts there's a whole frame wait)
I'm not sure if it happens—it doesn't seem like it.
https://github.com/user-attachments/assets/1c960f4d-f49c-4b76-b883-7fada8b1f167
https://github.com/user-attachments/assets/23ab1b72-e374-43af-971f-39dea67db7e4
I think a simple fix might be to pause execution if a frame takes too long to complete.
I think some action should be taken before the browser or OS shows a "not responding" warning. Most users will probably close the page after it indicates that it is not responding, rather than waiting for several minutes.