Hyper: unresponsive after many render updates while app is hidden

[juliangruber]

• [x] I am on the latest Hyper.app version
• [x] I have searched the issues of this repo and believe that this is not a duplicate

• OS version and name: macOS 10.12.13
• Hyper.app version: 1.3.1
• Link of a Gist with the contents of your .hyper.js: https://gist.github.com/juliangruber/8ba854b0f6a022ff188d64b59c315364
• Relevant information from devtools _(CMD+ALT+I on Mac OS, CTRL+SHIFT+I elsewhere)_: N/A (unresponsive)
• The issue is reproducible in vanilla Hyper.app: Yes

Issue

When you run a long running command that re-renders its content frequently - say because it displays a spinner - it's common to background the app and come back to it later. If I don't background the app, everything works as excepted. However, when I do, and I come back, hyper is completely unresponsive and the output has stalled some time ago. You can't input, can't open the dev tools, and no fresh output is rendered.

I get the impression that it's batching up all the updates until the app is visible again, and then is stuck on that?

A way to test this is to run https://github.com/juliangruber/travis-watch on a travis enabled project where builds take a long time. Start the watch process, background hyper, come back after a few minutes.

Thanks!

[JacobDB]

I'm seeing this on Windows 10 15063 in addition to Mac OS 10.12.13. I've seen it occur during a gulp watch, and during particularly long apt-get installs via SSH.

[lucianochavez2]

I ssh from my macbook to linux boxes doing long builds producing lots of output and I think I see the same issue. When it freezes though, hitting the keyboard shortcut to open a new tab doesn't work and if I have multiple tabs, the keyboard shortcut to cycle through them doesn't work either. I have to select the Quit Hyper menu option and start up Hyper again. Does that match this issue? Only plugins I have limited Hyper to are "hyperterm-atom-dark" for the theme but it still happens. I am running MacOS 10.12.14.

[shockey]

I'm seeing this too, when doing npm installs and then going back to my browser.

Started about a week ago for me. Pretty painful- I've gone back to using Terminal.app until this is fixed :/

[kevinelliott]

I am seeing this too.

[juliangruber]

Maybe a way to fix this is to implement a capped queue for requestanimationframe calls, so they don't batch up infinitely

[juliangruber]

I'm seeing this with the dat-desktop app too, and there I know it's just too many queued up render fns which all get called once the window is showed again

[opensourceportfolio]

I've just encountered that with karma test runs

[thepixelninja]

Also seeing this when running gulp or grunt watch and having hyper open in the background. Really bad when having gulp watch and a python server running in adjacent panels both of which spit out their output to the terminal whilst constantly working on a website.

[andig]

When you run a long running command that re-renders its content frequently - say because it displays a spinner - it's common to background the app and come back to it later. If I don't background the app, everything works as excepted. However, when I do, and I come back, hyper is completely unresponsive and the output has stalled some time ago. You can't input, can't open the dev tools, and no fresh output is rendered.

I'm seeing this too, on OSX, with the addition that it also seems to freeze when lots of output is produced in a non-visible tab, not necessarily only when hyper is run in background.

[pgsill]

Is there a workaround so this problem isn't as frequent? I wouldn't mind a temporary performance hit until this issue is fixed if it meant that Hyper is actually usable.

[Stanzilla]

Hey there, please try again with the new Hyper v2 release and open a new issue if the problem stills exists. Thank you!