Writing

When a single number broke a customer’s project

How a gap of 0 froze a customer’s canvas, and how half a dozen people across Framer tracked it down in a day.

Last week, a Framer user opened their project and ran into an issue: the canvas wouldn’t load. The cause turned out to be one of the more interesting bugs we’ve seen in a while, and how the team handled it is a good window into how teams at Framer actually work day-to-day.

Slack support request about a customer project stuck loading because of an unresponsive canvas

What was happening

The issue traced back to a single component from the Marketplace and a single property the user had changed.

The component was a curved ticker: animated text that loops along a curve. A cool effect, well-built, available on the Marketplace for a while. The bug only appeared in a very specific edge case: when its gap property was set to 0.

That value triggered an infinite loop in the component’s render logic. Every render kept pushing new items into an array forever, which blocked the main thread. The sandbox couldn’t even report that something was wrong. The only signal from the logs was a quiet “Canvas is unresponsive”, which didn’t explain the cause.

How the team got there
This is the part nobody really sees from the outside, and the part I think is most worth sharing.
@Volagn picked up the investigation and traced the call stack in Chrome Dev Tools. Memory was fine, only a handful of DOM nodes had rendered before the freeze, and the heartbeat the sandbox sends back to the canvas was sitting at zero. That zero was the clue: something was running indefinitely and blocking everything else. From there, it was a matter of narrowing down which of the loaded modules was the culprit.
Memory:    23 MB used / 4 GB limit   ✓ fine
DOM nodes: 109                       ✓ fine
Heartbeat: 0                         ✗ stuck
Updates:   0


Memory:    23 MB used / 4 GB limit   ✓ fine
DOM nodes: 109                       ✓ fine
Heartbeat: 0                         ✗ stuck
Updates:   0


Memory:    23 MB used / 4 GB limit   ✓ fine
DOM nodes: 109                       ✓ fine
Heartbeat: 0                         ✗ stuck
Updates:   0


The next morning, @daniela_dias pulled the project’s last good version, a snapshot taken right before that one property was changed, and confirmed the diagnosis.
From there it became a coordination problem.
@hemlok_ and Daniela worked through how to get the user back into a working version of their project without losing any work. They built a duplicate from the good snapshot. When the preview still didn’t load on the duplicate, we figured out it was pulling a cached version of the component and forced a fresh recompile. Then it worked!
By the time we replied to the user with the working link, around six people had touched the investigation. Each one moved the puzzle a little further along.
Closing the loop
Once the user was unblocked, we reached out to the component creator with the full diagnosis and a suggested fix: a single line of code. They pushed an update quickly, and the component was back on the Marketplace in no time.
- const totalItemWidth = childrenArray.length * gap
+ const totalItemWidth = childrenArray.length * Math.max(gap, 1)
- const totalItemWidth = childrenArray.length * gap
+ const totalItemWidth = childrenArray.length * Math.max(gap, 1)
- const totalItemWidth = childrenArray.length * gap
+ const totalItemWidth = childrenArray.length * Math.max(gap, 1)
What I love about working at Framer is moments like this. A weird edge case turns up, and within a day, half a dozen people across teams have collaborated to solve it, fix the underlying bug, and make sure the user’s work is safe. Every time we work through one of these, the platform gets a little stronger, and so does the playbook for the next one.