Cassette crashes if left running in background tab during extended period

Question

Cassette crashes if left running in background tab during extended period

Closed this issue 6 years ago · 16 comments

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?

benwiley4000 commented 6 years ago

Thanks!

Answer 1 · 2019-02-18T15:49:30.000Z

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

Answer 2 · 2019-02-18T15:51:23.000Z

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.

Answer 3 · 2019-02-18T15:53:46.000Z

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.

Answer 4 · 2019-02-19T12:34:49.000Z

This thread seems to be describing a very similar issue: c3js/c3#956

Answer 5 · 2019-02-19T13:17:11.000Z

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

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

Answer 6 · 2019-02-19T13:29:48.000Z

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.

Answer 7 · 2019-02-19T13:32:43.000Z

Thanks for looking at this btw!

Answer 8 · 2019-02-19T14:04:51.000Z

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: facebook/react#14888

Answer 9 · 2019-02-19T14:07:44.000Z

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

Answer 10 · 2019-02-19T14:12:10.000Z

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.

Answer 11 · 2019-02-19T14:36:32.000Z

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.

Answer 12 · 2019-02-20T01:41:46.000Z

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

Answer 13 · 2019-02-20T01:50:05.000Z

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)

Answer 14 · 2019-02-20T01:50:50.000Z

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

Answer 15 · 2019-02-20T01:51:33.000Z

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