Is Stripe Checkout leaking memory?

Question

The issue I'm seeing is that when you load Stripe Checkout into a page using their canonical "Custom" guide, configure it, and then open and close it a few times, the browser memory usage continually jumps. It sometimes, sorta gets released a little, but the residual always grows. And on a long lived page/SPA, eventually things crawl.

1. Start Google Chrome with --enable-precise-memory-info flag (issue happens with or without this flag)
2. Copy the "Custom" example on their site: https://stripe.com/docs/checkout#integration-custom (or use your own setup, the results are the same).
3. Click the 'Purchase' button (or trigger your stripeInstance.open(cfg) ), fiddle with the popup, close.
4. Repeat step 3, watch memory gradually 💥

You can watch memory with memory-stats.js or just by running in (Chrome) console:

performance.memory.usedJSHeapSize

I'm convinced this has to be "me" and not Stripe. No way they'd leak so bad on open and close events right?

---

Edit: Here's a JS fiddle that literally copies their demo code: https://jsfiddle.net/p1Lfuewt/

And a 5 second interval screen shot of memory with basically just opening and closing their widget by clicking "purchase" (no idea what that promise error is, that's them):

Answer 1

It is not possible to know for sure, but they could be retaining some data that it is never freed or it could be chrome's java script engine that try to have everything cached for the future. You should try to leave the page alone some time and see if the cache memory goes down.

Answer 2

Short answer, yes.

The longer answer is, it sure seems like it. The attached JSFiddle example replicates the Stripe canonical docs , and it's trivial to replicate the issue of memory blowing out on the simple act of opening and closing Stripe's widget.

handler.open({
  name: 'Stripe.com',
  description: '2 widgets',
  zipCode: true,
  amount: 2000
})
// Repeat for 💥

A (terrible) workaround we implemented was tracking the number of opens+closes events and forcing a hard reload after X events for edge cases reaching those levels.