Cassette crashes if left running in background tab during extended period

[benwiley4000]

Causing the style guide to become unresponsive when left alone for awhile. Requires killing the page with the Chrome task manager because attempting to close the tab normally doesn't work.

Unclear if this is a bug with the style guide or with Cassette itself but either way I don't want that.

@danielr18 have you experienced anything like this with your app?

[danielr18]

Haven't experienced that, let me try to recreate it. Just leaving the page open?

[benwiley4000]

Yeah, I think I left it going when I put my computer to sleep last night and since I resumed this morning I've kept it going in the background playing the demo tracks. I think the music was still going but the screen had turned completely white and I couldn't interact with anything. So I have no idea at what point it became non-responsive.

[benwiley4000]

I also have over 100 chrome tabs open so not sure if that affects things, but this didn't happen in any of my other tabs, so I wouldn't assume that's it.

[benwiley4000]

This thread seems to be describing a very similar issue: https://github.com/c3js/c3/issues/956

[danielr18]

Steps: 1 - Played an episode 2 - Minimised the tab

I've seen ~40mb increase in an hour, tab is still minimised.

[benwiley4000]

I nailed down better what the issue is I think. I don't think you're using the MaybeMarquee component but that's the main culprit. You have to open a new tab in the foreground. All the deferred requestAnimationFrames from MaybeMarquee get run all at once to make up for lost time when the tab is restored from the background.

The other issue seems to be from the setState calls on timeupdate which trigger requestAnimationFrame calls in React. They also get deferred, but they don't happen nearly as often so they don't build up so fast.

[benwiley4000]

Thanks for looking at this btw!

[benwiley4000]

I haven't figured out how to best deal with the context subscription issue yet. I opened an issue in React because I sort of think they should deal with this: https://github.com/facebook/react/issues/14888

[danielr18]

What if we used Page Visibility API to prevent those setState calls?

[benwiley4000]

I'd like to do something like that. I'm deferring the animation for the maybemarquee but it's a bit more complicated with these setState calls because there's stuff that needs to happen after the state is updated.. basically everything that runs in componentDidUpdate. So my idea was to defer creating a new playerContext value until after document.hidden is false again. Haven't figured out any implementation details though.

[benwiley4000]

Ha! Just realized this RAF is my fault. It's coming from the helper code for the docs. I should be able to come up with a solution, but the larger point is, not part of the core library I think.

[danielr18]

At the end of the day, the total memory increase was around 200mb.

[benwiley4000]

Wait, that is pretty huge. We're you able to get a heap snapshot? (Can't remember if that's in Chrome or only Firefox)

[benwiley4000]

I'll cut a new release soon so you can test it with the new version if you want.

[danielr18]

Too late, closed the tab a few mins ago. I'll leave it running overnight and take a snapshot in the morning.

[benwiley4000]

Thanks!