Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[2.0] Chaining promises hangs browser (100% CPU) #876

Open
Tarpsvo opened this issue May 29, 2018 · 1 comment
Open

[2.0] Chaining promises hangs browser (100% CPU) #876

Tarpsvo opened this issue May 29, 2018 · 1 comment
Labels

Comments

@Tarpsvo
Copy link

Tarpsvo commented May 29, 2018

Your system information

  • VelocityJS version: 2.0.4
  • Browser: Chrome 66.0.3359.181
  • Operating System: Reproduced on Windows 10 and MacOS 10.13.2

Please describe your issue in as much detail as possible:

Chaining multiple velocity.js promises hangs the Chrome tab and requires the tab to be force killed through task manager, as it no longer reacts to regular exit codes. The processor usage for the tab's process is stuck at 100%.

Steps for reproducing this issue (code):

Minimal code example, using 2.0.4 from CDN: https://jsfiddle.net/Tarps/6kjLrujx/

Pressing "Try animation" button freezes the Chrome browser. Be ready to force quit the tab using Chrome's task manager.


This is essentially a continuation of #868

@Rycochet Rycochet added the Bug label May 29, 2018
@Rycochet
Copy link
Collaborator

This is a seriously annoying one. I've cleaned up code slightly, but the problem is that Velocity returns a Promise, which is attached to an object that is then used to resolve the promise, and it seems to get stuck in an infinite loop.

I'm stuck on how to fix it right now, but have an inkling of an idea in returning a different promise to the one that is resolved, and then resolving the one that's returned while having the first .then actually override whatever it outputs with the true output... It's going around in circles and not quite joining the dots - so any help would be appreciated.

I do feel this almost qualifies as a slight break in the spec itself - as there's nothing in it about trying to resolve a promise with itself, and I feel that's overlooked (so undefined behaviour in this case causes a lockup without any major memory issues that I can see).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants